Overview

ভূমিকা

দ্রষ্টব্য: এই ডকুমেন্টেশনটি এখনও বিকাশাধীন। অদূর ভবিষ্যতে উন্নতি আশা করুন.

Google Safe Browsing v5 হল Google Safe Browsing v4 এর একটি বিবর্তন। v5-এ করা দুটি মূল পরিবর্তন হল ডেটা সতেজতা এবং IP গোপনীয়তা। উপরন্তু, নমনীয়তা, দক্ষতা বাড়াতে এবং ফোলা কমাতে API পৃষ্ঠকে উন্নত করা হয়েছে। উপরন্তু, Google নিরাপদ ব্রাউজিং v5 ডিজাইন করা হয়েছে v4 থেকে মাইগ্রেশন সহজ করার জন্য।

বর্তমানে, Google v4 এবং v5 উভয়ই অফার করে এবং উভয়কেই উৎপাদন প্রস্তুত বলে মনে করা হয়। আপনি v4 বা v5 ব্যবহার করতে পারেন। আমরা v4 সূর্যাস্তের তারিখ ঘোষণা করিনি; যদি আমরা তা করি, আমরা ন্যূনতম এক বছরের নোটিশ দেব। এই পৃষ্ঠাটি v5 বর্ণনা করবে সেই সাথে v4 থেকে v5 পর্যন্ত একটি মাইগ্রেশন গাইড; সম্পূর্ণ v4 ডকুমেন্টেশন উপলব্ধ থাকে।

ডেটা সতেজতা

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

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

আইপি গোপনীয়তা

Google নিরাপদ ব্রাউজিং (v4 বা v5) অনুরোধ পরিবেশনের সময় ব্যবহারকারীর পরিচয়ের সাথে সম্পর্কিত কিছু প্রক্রিয়া করে না। কুকিজ, যদি পাঠানো হয়, উপেক্ষা করা হয়. অনুরোধগুলির মূল আইপি ঠিকানাগুলি Google-এর কাছে পরিচিত, তবে Google শুধুমাত্র প্রয়োজনীয় নেটওয়ার্কিং প্রয়োজনের জন্য (যেমন প্রতিক্রিয়া পাঠানোর জন্য) এবং অ্যান্টি-ডিওএস উদ্দেশ্যে আইপি ঠিকানাগুলি ব্যবহার করে৷

একই সাথে v5 এর সাথে, আমরা একটি সহচর API প্রবর্তন করি যা সেফ ব্রাউজিং অবলিভিয়স HTTP গেটওয়ে API নামে পরিচিত। এটি Google থেকে শেষ ব্যবহারকারীদের আইপি ঠিকানা লুকানোর জন্য অবলিভিস HTTP ব্যবহার করে। এটি ব্যবহারকারীর অনুরোধের একটি এনক্রিপ্ট করা সংস্করণ পরিচালনা করার জন্য একটি নন-ক্লুডিং থার্ড-পার্টি থাকার মাধ্যমে কাজ করে এবং তারপর সেটি Google-এ ফরওয়ার্ড করে। সুতরাং তৃতীয় পক্ষের শুধুমাত্র আইপি ঠিকানাগুলিতে অ্যাক্সেস রয়েছে এবং Google শুধুমাত্র অনুরোধের বিষয়বস্তুতে অ্যাক্সেস করতে পারে। তৃতীয় পক্ষ একটি অবলিভিস এইচটিটিপি রিলে পরিচালনা করে (যেমন ফাস্টলি দ্বারা এই পরিষেবাটি ), এবং Google অবলিভিস এইচটিটিপি গেটওয়ে পরিচালনা করে। এটি একটি ঐচ্ছিক সহচর API। Google নিরাপদ ব্রাউজিংয়ের সাথে এটি ব্যবহার করার সময়, শেষ ব্যবহারকারীদের আইপি ঠিকানা আর Google-এ পাঠানো হয় না।

উপযুক্ত ব্যবহার

অনুমোদিত ব্যবহার

নিরাপদ ব্রাউজিং API শুধুমাত্র অ-বাণিজ্যিক ব্যবহারের জন্য (অর্থাৎ "বিক্রয় বা উপার্জনের উদ্দেশ্যে নয়")। আপনার যদি বাণিজ্যিক উদ্দেশ্যে সমাধানের প্রয়োজন হয়, অনুগ্রহ করে ওয়েব রিস্ক দেখুন।

মূল্য নির্ধারণ

সমস্ত Google নিরাপদ ব্রাউজিং এপিআই বিনামূল্যে।

কোটা

সেফ ব্রাউজিং এপিআই সক্ষম করার পরে বিকাশকারীদের একটি ডিফল্ট ব্যবহারের কোটা বরাদ্দ করা হয়। বর্তমান বরাদ্দ এবং ব্যবহার Google ডেভেলপার কনসোলে দেখা যেতে পারে। আপনি যদি আপনার বর্তমানে বরাদ্দকৃত কোটার চেয়ে বেশি ব্যবহার করার আশা করেন, তাহলে আপনি বিকাশকারী কনসোলের কোটা ইন্টারফেস থেকে অতিরিক্ত কোটার অনুরোধ করতে পারেন। আমরা এই অনুরোধগুলি পর্যালোচনা করি এবং বর্ধিত কোটার জন্য আবেদন করার সময় আমাদের পরিষেবার প্রাপ্যতা সমস্ত ব্যবহারকারীর চাহিদা পূরণ করে তা নিশ্চিত করার জন্য একটি যোগাযোগের প্রয়োজন৷

উপযুক্ত ইউআরএল

Google নিরাপদ ব্রাউজিং একটি ব্রাউজারের ঠিকানা বারে প্রদর্শিত URL গুলিতে কাজ করার জন্য ডিজাইন করা হয়েছে৷ এটি সাবরিসোর্স (যেমন একটি জাভাস্ক্রিপ্ট বা একটি HTML ফাইল দ্বারা উল্লেখ করা ছবি, বা JavaScript দ্বারা শুরু করা একটি WebSocket URL) এর বিরুদ্ধে পরীক্ষা করার জন্য ডিজাইন করা হয়নি৷ এই ধরনের সাবরিসোর্স ইউআরএলগুলিকে গুগল সেফ ব্রাউজিং এর বিরুদ্ধে চেক করা উচিত নয় ।

যদি একটি URL পরিদর্শনের ফলে একটি পুনঃনির্দেশ হয় (যেমন HTTP 301), তাহলে Google নিরাপদ ব্রাউজিং-এর বিরুদ্ধে পুনঃনির্দেশিত URL চেক করা উপযুক্ত৷ ক্লায়েন্ট-সাইড ইউআরএল ম্যানিপুলেশন যেমন History.pushState এর ফলে Google সেফ ব্রাউজিংয়ের বিরুদ্ধে নতুন ইউআরএল চেক করা হয় না ।

ব্যবহারকারী সতর্কতা

আপনি যদি নির্দিষ্ট ওয়েবপৃষ্ঠাগুলির ঝুঁকি সম্পর্কে ব্যবহারকারীদের সতর্ক করার জন্য Google নিরাপদ ব্রাউজিং ব্যবহার করেন তবে নিম্নলিখিত নির্দেশিকা প্রযোজ্য হবে৷

এই নির্দেশিকাগুলি আপনাকে এবং Google উভয়কে ভুল বোঝাবুঝি থেকে রক্ষা করতে সাহায্য করে এই স্পষ্ট করে যে পৃষ্ঠাটি একটি অনিরাপদ ওয়েব সংস্থান হওয়ার 100% নিশ্চিততার সাথে পরিচিত নয় এবং সতর্কতাগুলি কেবল সম্ভাব্য ঝুঁকি চিহ্নিত করে৷

• আপনার ব্যবহারকারীর দৃশ্যমান সতর্কতায়, আপনি অবশ্যই ব্যবহারকারীদের বিশ্বাস করতে বাধ্য করবেন না যে প্রশ্নে থাকা পৃষ্ঠাটি নিঃসন্দেহে একটি অনিরাপদ ওয়েব সম্পদ। আপনি যখন শনাক্ত করা পৃষ্ঠার উল্লেখ করেন বা এটি ব্যবহারকারীদের জন্য সম্ভাব্য ঝুঁকির কারণ হতে পারে, তখন আপনাকে অবশ্যই এই ধরনের পদগুলি ব্যবহার করে সতর্কতা যোগ্য করতে হবে: সন্দেহজনক, সম্ভাব্য, সম্ভাব্য, সম্ভাব্য, হতে পারে।
• আপনার সতর্কতা অবশ্যই ব্যবহারকারীকে Google-এর বিভিন্ন হুমকির সংজ্ঞা পর্যালোচনা করে আরও জানতে সক্ষম করবে৷ নিম্নলিখিত লিঙ্কগুলি সুপারিশ করা হয়:
  • সামাজিক প্রকৌশল: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • ম্যালওয়্যার এবং অবাঞ্ছিত সফ্টওয়্যার: https://developers.google.com/search/docs/monitor-debug/security/malware
  • সম্ভাব্য ক্ষতিকারক অ্যাপ্লিকেশন (শুধুমাত্র অ্যান্ড্রয়েড): https://developers.google.com/android/play-protect/potentially-harmful-applications
• আপনি যখন নিরাপদ ব্রাউজিং পরিষেবা দ্বারা ঝুঁকিপূর্ণ হিসাবে চিহ্নিত পৃষ্ঠাগুলির জন্য সতর্কতা দেখান, তখন আপনাকে অবশ্যই নিরাপদ ব্রাউজিং পরামর্শের লিঙ্কের সাথে "গুগলের দেওয়া পরামর্শ" লাইনটি অন্তর্ভুক্ত করে Google-কে অ্যাট্রিবিউশন দিতে হবে। যদি আপনার পণ্য অন্যান্য উত্সের উপর ভিত্তি করে সতর্কতাগুলিও দেখায়, তাহলে আপনাকে অবশ্যই নন-Google ডেটা থেকে প্রাপ্ত সতর্কতায় Google অ্যাট্রিবিউশন অন্তর্ভুক্ত করতে হবে না।

• আপনার পণ্যের ডকুমেন্টেশনে, ব্যবহারকারীদের জানানোর জন্য আপনাকে অবশ্যই একটি নোটিশ প্রদান করতে হবে যে Google সেফ ব্রাউজিং দ্বারা প্রদত্ত সুরক্ষা নিখুঁত নয়। এটি তাদের অবশ্যই জানাতে হবে যে মিথ্যা ইতিবাচক (নিরাপদ সাইটগুলিকে ঝুঁকিপূর্ণ হিসাবে পতাকাঙ্কিত) এবং মিথ্যা নেতিবাচক (ঝুঁকিপূর্ণ সাইটগুলি পতাকাঙ্কিত নয়) উভয়েরই সম্ভাবনা রয়েছে৷ আমরা নিম্নলিখিত ভাষা ব্যবহার করার পরামর্শ দিই:

  Google অনিরাপদ ওয়েব রিসোর্স সম্পর্কে সবচেয়ে সঠিক এবং আপ-টু-ডেট তথ্য প্রদান করতে কাজ করে। যাইহোক, Google গ্যারান্টি দিতে পারে না যে তার তথ্য ব্যাপক এবং ত্রুটি-মুক্ত: কিছু ঝুঁকিপূর্ণ সাইট সনাক্ত করা যাবে না, এবং কিছু নিরাপদ সাইট ত্রুটিতে সনাক্ত করা যেতে পারে।

অপারেশন মোড

Google নিরাপদ ব্রাউজিং v5 ক্লায়েন্টদের অপারেশনের তিনটি মোড থেকে বেছে নিতে দেয়।

রিয়েল-টাইম মোড

যখন ক্লায়েন্টরা রিয়েল-টাইম মোডে Google Safe Browsing v5 ব্যবহার করতে বেছে নেয়, তখন ক্লায়েন্টরা তাদের স্থানীয় ডাটাবেসে বজায় রাখবে: (i) সম্ভাব্য-সৌম্য সাইটগুলির একটি গ্লোবাল ক্যাশে, হোস্ট-সফিক্স/পাথ-প্রিফিক্স URL এক্সপ্রেশনগুলির SHA256 হ্যাশ হিসাবে ফর্ম্যাট করা হয়েছে, (ii) হুমকি তালিকার একটি সেট, হোস্ট-সফিক্স/পাথ-প্রিফিক্স URL এক্সপ্রেশনের SHA256 হ্যাশ উপসর্গ হিসাবে ফর্ম্যাট করা হয়েছে। উচ্চ-স্তরের ধারণা হল যে যখনই ক্লায়েন্ট একটি নির্দিষ্ট URL চেক করতে চায়, তখন গ্লোবাল ক্যাশে ব্যবহার করে একটি স্থানীয় চেক করা হয়। যদি সেই চেকটি পাস হয়, একটি স্থানীয় হুমকি তালিকা চেক করা হয়। অন্যথায়, ক্লায়েন্ট রিয়েল-টাইম হ্যাশ চেকটি নীচে বিশদভাবে চালিয়ে যান।

স্থানীয় ডাটাবেস ছাড়াও, ক্লায়েন্ট একটি স্থানীয় ক্যাশে বজায় রাখবে। এই ধরনের একটি স্থানীয় ক্যাশে ক্রমাগত স্টোরেজের প্রয়োজন নেই এবং মেমরির চাপের ক্ষেত্রে সাফ করা যেতে পারে।

পদ্ধতির একটি বিশদ বিবরণ নীচে উপলব্ধ।

স্থানীয় তালিকা মোড

যখন ক্লায়েন্টরা এই মোডে Google সেফ ব্রাউজিং v5 ব্যবহার করতে বেছে নেয়, তখন ক্লায়েন্টের আচরণ v4 আপডেট API-এর মতোই হয় v5-এর উন্নত API সারফেস ব্যবহার করা ছাড়া। ক্লায়েন্টরা তাদের স্থানীয় ডাটাবেসে হোস্ট-সফিক্স/পাথ-প্রিফিক্স URL এক্সপ্রেশনের SHA256 হ্যাশ উপসর্গ হিসাবে ফর্ম্যাট করা হুমকি তালিকার একটি সেট বজায় রাখবে। যখনই ক্লায়েন্ট একটি নির্দিষ্ট URL পরীক্ষা করতে চায়, স্থানীয় হুমকি তালিকা ব্যবহার করে একটি চেক করা হয়। যদি এবং শুধুমাত্র যদি একটি মিল থাকে, ক্লায়েন্ট চেক চালিয়ে যেতে সার্ভারের সাথে সংযোগ করে।

উপরের মতো, ক্লায়েন্ট একটি স্থানীয় ক্যাশেও বজায় রাখবে যা স্থায়ী সঞ্চয়স্থানে থাকার প্রয়োজন নেই।

নো-স্টোরেজ রিয়েল-টাইম মোড

ক্লায়েন্টরা যখন নো-স্টোরেজ রিয়েল-টাইম মোডে Google সেফ ব্রাউজিং v5 ব্যবহার করতে বেছে নেয়, তখন ক্লায়েন্টের কোনো স্থায়ী স্থানীয় ডাটাবেস বজায় রাখার প্রয়োজন হয় না। যাইহোক, ক্লায়েন্ট এখনও একটি স্থানীয় ক্যাশে বজায় রাখার প্রত্যাশিত৷ এই ধরনের একটি স্থানীয় ক্যাশে ক্রমাগত স্টোরেজের প্রয়োজন নেই এবং মেমরির চাপের ক্ষেত্রে সাফ করা যেতে পারে।

যখনই ক্লায়েন্ট একটি নির্দিষ্ট URL চেক করতে চায়, ক্লায়েন্ট সর্বদা সার্ভারের সাথে একটি চেক করার জন্য সংযোগ করে। এই মোডটি v4 Lookup API-এর ক্লায়েন্টরা যা প্রয়োগ করতে পারে তার অনুরূপ।

রিয়েল-টাইম মোডের তুলনায়, এই মোডটি আরও বেশি নেটওয়ার্ক ব্যান্ডউইথ ব্যবহার করতে পারে কিন্তু ক্লায়েন্টের পক্ষে স্থায়ী স্থানীয় অবস্থা বজায় রাখা অসুবিধাজনক হলে এটি আরও উপযুক্ত হতে পারে।

ইউআরএল চেক করা হচ্ছে

এই বিভাগে ক্লায়েন্ট কিভাবে URL চেক করে তার বিস্তারিত বিবরণ রয়েছে।

ইউআরএলের ক্যানোনিকালাইজেশন

কোনো ইউআরএল চেক করার আগে, ক্লায়েন্ট সেই ইউআরএলে কিছু ক্যানোনিকালাইজেশন করবে বলে আশা করা হয়।

শুরু করার জন্য, আমরা ধরে নিই যে ক্লায়েন্ট URLটিকে পার্স করেছে এবং RFC 2396 অনুযায়ী এটি বৈধ করেছে৷ যদি URLটি একটি আন্তর্জাতিক ডোমেন নাম (IDN) ব্যবহার করে, তাহলে ক্লায়েন্টকে URLটিকে ASCII Punycode উপস্থাপনায় রূপান্তর করতে হবে৷ URL একটি পাথ উপাদান অন্তর্ভুক্ত করা আবশ্যক; অর্থাৎ, ডোমেন অনুসরণ করে কমপক্ষে একটি স্ল্যাশ থাকতে হবে ( http://google.com/ এর পরিবর্তে http://google.com )।

প্রথমে, URL থেকে ট্যাব (0x09), CR (0x0d), এবং LF (0x0a) অক্ষরগুলি সরান৷ এই অক্ষরগুলির জন্য এস্কেপ সিকোয়েন্সগুলি সরিয়ে ফেলবেন না (যেমন %0a )।

দ্বিতীয়ত, যদি URL একটি খণ্ডে শেষ হয়, তাহলে খণ্ডটি সরান। উদাহরণস্বরূপ, http://google.com/#frag কে http://google.com/ এ ছোট করুন।

তৃতীয়ত, বারবার ইউআরএল-কে পার্সেন্ট-আনস্কেপ করুন যতক্ষণ না এতে আর শতাংশ-এস্কেপ না হয়। (এটি URLটিকে অবৈধ রেন্ডার করতে পারে।)

হোস্টনামটিকে ক্যানোনিকালাইজ করতে:

URL থেকে হোস্টনাম বের করুন এবং তারপর:

1. সমস্ত অগ্রণী এবং পিছনের বিন্দুগুলি সরান৷
2. একটি একক বিন্দু দিয়ে পরপর বিন্দু প্রতিস্থাপন করুন।
3. যদি হোস্টনামটি একটি IPv4 ঠিকানা হিসাবে পার্স করা যায়, তাহলে এটিকে 4 ডট-বিভাজিত দশমিক মানগুলিতে স্বাভাবিক করুন। ক্লায়েন্টকে অক্টাল, হেক্স এবং চারটিরও কম উপাদান সহ যেকোনো আইনি আইপি-ঠিকানা এনকোডিং পরিচালনা করা উচিত।
4. যদি হোস্টনামটিকে একটি বন্ধনীযুক্ত IPv6 ঠিকানা হিসাবে পার্স করা যায়, তাহলে উপাদানগুলির মধ্যে অপ্রয়োজনীয় অগ্রণী শূন্যগুলি সরিয়ে এবং ডাবল-কোলন সিনট্যাক্স ব্যবহার করে শূন্য উপাদানগুলি ভেঙে দিয়ে এটিকে স্বাভাবিক করুন। উদাহরণস্বরূপ [2001:0db8:0000::1] কে [2001:db8::1] এ রূপান্তরিত করা উচিত। যদি হোস্টনামটি নিম্নলিখিত দুটি বিশেষ IPv6 ঠিকানা প্রকারের মধ্যে একটি হয়, তাহলে তাদের IPv4 এ রূপান্তর করুন:
   • একটি IPv4-ম্যাপ করা IPv6 ঠিকানা, যেমন [::ffff:1.2.3.4] , যা 1.2.3.4 এ রূপান্তরিত হওয়া উচিত;
   • একটি NAT64 ঠিকানা সুপরিচিত উপসর্গ ব্যবহার করে 64:ff9b::/96 , যেমন [64:ff9b::1.2.3.4] , যা 1.2.3.4 এ রূপান্তরিত হওয়া উচিত।
5. পুরো স্ট্রিং ছোট হাতের অক্ষর.

পথটিকে আদর্শীকরণ করতে:

1. /../ / /./ এবং /../ পূর্ববর্তী পাথ উপাদানের সাথে প্রতিস্থাপন করে /../ এবং /./ পাথের ক্রমগুলি সমাধান করুন৷
2. একটানা স্ল্যাশের রানগুলিকে একটি একক স্ল্যাশ অক্ষর দিয়ে প্রতিস্থাপন করুন।

ক্যোয়ারী প্যারামিটারে এই পাথ ক্যানোনিকালাইজেশন প্রয়োগ করবেন না।

URL-এ, <= ASCII 32, >= 127, # , বা % সমস্ত অক্ষর শতাংশ-এস্কেপ করুন। এস্কেপগুলিতে বড় হাতের হেক্স অক্ষর ব্যবহার করা উচিত।

হোস্ট-প্রত্যয় পাথ-প্রিফিক্স এক্সপ্রেশন

একবার ইউআরএল ক্যানোনিকালাইজ করা হলে, পরবর্তী ধাপ হল প্রত্যয়/প্রিফিক্স এক্সপ্রেশন তৈরি করা। প্রতিটি প্রত্যয়/প্রিফিক্স এক্সপ্রেশনে একটি হোস্ট প্রত্যয় (বা সম্পূর্ণ হোস্ট) এবং একটি পাথ উপসর্গ (বা সম্পূর্ণ পথ) থাকে।

ক্লায়েন্ট 30টি পর্যন্ত বিভিন্ন সম্ভাব্য হোস্ট প্রত্যয় এবং পথ উপসর্গ সমন্বয় গঠন করবে। এই সমন্বয় শুধুমাত্র URL এর হোস্ট এবং পাথ উপাদান ব্যবহার করে। স্কিম, ব্যবহারকারীর নাম, পাসওয়ার্ড এবং পোর্ট বাতিল করা হয়েছে। যদি URL-এ ক্যোয়ারী প্যারামিটার থাকে, তাহলে অন্তত একটি সংমিশ্রণে সম্পূর্ণ পাথ এবং ক্যোয়ারী প্যারামিটার অন্তর্ভুক্ত থাকবে।

হোস্টের জন্য , ক্লায়েন্ট সর্বোচ্চ পাঁচটি ভিন্ন স্ট্রিং চেষ্টা করবে। তারা হল:

• হোস্টনামটি যদি IPv4 বা IPv6 আক্ষরিক না হয়, তাহলে eTLD+1 ডোমেন দিয়ে শুরু করে এবং পরপর লিডিং কম্পোনেন্ট যোগ করে চারটি হোস্টনাম তৈরি হয়। eTLD+1-এর নির্ধারণ পাবলিক সাফিক্স তালিকার উপর ভিত্তি করে হওয়া উচিত। উদাহরণ স্বরূপ, abexample.com এর ফলে example.com এর eTLD+1 ডোমেইনের পাশাপাশি একটি অতিরিক্ত হোস্ট উপাদান b.example.com এর সাথে হোস্ট হবে।
• URL-এ সঠিক হোস্টনাম। আগের উদাহরণ অনুসরণ করে, abexample.com চেক করা হবে।

পথের জন্য , ক্লায়েন্ট সর্বোচ্চ ছয়টি ভিন্ন স্ট্রিং চেষ্টা করবে। তারা হল:

• ক্যোয়ারী প্যারামিটার সহ URL-এর সঠিক পথ।
• ক্যোয়ারী প্যারামিটার ছাড়াই URL-এর সঠিক পথ।
• চারটি পাথ রুট (/) থেকে শুরু করে এবং একটি ট্রেইলিং স্ল্যাশ সহ পর্যায়ক্রমে পাথ উপাদান যুক্ত করে গঠিত হয়।

নিম্নলিখিত উদাহরণগুলি চেকের আচরণকে চিত্রিত করে:

URL http://abcom/1/2.html?param=1 এর জন্য, ক্লায়েন্ট এই সম্ভাব্য স্ট্রিংগুলি চেষ্টা করবে:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

URL http://abcdefcom/1.html এর জন্য, ক্লায়েন্ট এই সম্ভাব্য স্ট্রিংগুলি চেষ্টা করবে:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(দ্রষ্টব্য: bcdefcom এড়িয়ে যান, যেহেতু আমরা শুধুমাত্র শেষ পাঁচটি হোস্টনামের উপাদান এবং সম্পূর্ণ হোস্টনাম নেব।)

URL http://1.2.3.4/1/ এর জন্য, ক্লায়েন্ট এই সম্ভাব্য স্ট্রিংগুলি চেষ্টা করবে:

1.2.3.4/1/
1.2.3.4/

URL http://example.co.uk/1 এর জন্য, ক্লায়েন্ট এই সম্ভাব্য স্ট্রিংগুলি চেষ্টা করবে:

example.co.uk/1
example.co.uk/

হ্যাশিং

গুগল সেফ ব্রাউজিং একচেটিয়াভাবে হ্যাশ ফাংশন হিসাবে SHA256 ব্যবহার করে। এই হ্যাশ ফাংশন উপরের অভিব্যক্তি প্রয়োগ করা উচিত.

সম্পূর্ণ 32-বাইট হ্যাশ, পরিস্থিতির উপর নির্ভর করে, 4 বাইট, 8 বাইট, বা 16 বাইটে কাটা হবে:

• hashes.search পদ্ধতি ব্যবহার করার সময়, আমরা বর্তমানে অনুরোধে হ্যাশগুলিকে ঠিক 4 বাইটে ছোট করতে চাই। এই অনুরোধে অতিরিক্ত বাইট পাঠানো ব্যবহারকারীর গোপনীয়তার সাথে আপস করবে।

• hashList.get পদ্ধতি বা hashLists.batchGet পদ্ধতি ব্যবহার করে স্থানীয় ডাটাবেসের জন্য তালিকা ডাউনলোড করার সময়, সার্ভার দ্বারা পাঠানো হ্যাশের দৈর্ঘ্য তালিকার প্রকৃতি এবং হ্যাশ দৈর্ঘ্যের ক্লায়েন্টের পছন্দ উভয় দ্বারা প্রভাবিত হয়, যা দ্বারা যোগাযোগ করা হয় desired_hash_length প্যারামিটার।

রিয়েল-টাইম ইউআরএল চেক পদ্ধতি

এই পদ্ধতিটি ব্যবহৃত হয় যখন ক্লায়েন্ট অপারেশনের রিয়েল-টাইম মোড বেছে নেয়।

এই পদ্ধতিটি একটি একক URL u নেয় এবং SAFE , UNSAFE বা UNSURE ফেরত দেয়। যদি এটি SAFE ফিরে আসে তবে ইউআরএলটিকে Google নিরাপদ ব্রাউজিং দ্বারা নিরাপদ বলে মনে করা হবে। যদি এটি UNSAFE ফেরত দেয় তবে ইউআরএলটিকে Google সেফ ব্রাউজিং দ্বারা সম্ভাব্য অনিরাপদ বলে মনে করা হয় এবং উপযুক্ত ব্যবস্থা নেওয়া উচিত: যেমন শেষ ব্যবহারকারীকে একটি সতর্কতা দেখানো, স্প্যাম ফোল্ডারে একটি প্রাপ্ত বার্তা সরানো, বা এগিয়ে যাওয়ার আগে ব্যবহারকারীর দ্বারা অতিরিক্ত নিশ্চিতকরণের প্রয়োজন৷ যদি এটি UNSURE হয় তবে নিম্নলিখিত স্থানীয়-চেক পদ্ধতিটি পরে ব্যবহার করা উচিত।

1. expressions ইউআরএল u দ্বারা উত্পন্ন প্রত্যয়/প্রিফিক্স এক্সপ্রেশনের একটি তালিকা হতে দিন।
2. expressionHashes একটি তালিকা হতে দিন, যেখানে উপাদানগুলি প্রতিটি expressions এক্সপ্রেশনের SHA256 হ্যাশ।
3. expressionHashes প্রতিটি hash জন্য:
   1. যদি hash গ্লোবাল ক্যাশে পাওয়া যায়, তবে UNSURE ফেরত দিন।
4. expressionHashPrefixes একটি তালিকা করা যাক, যেখানে উপাদানগুলি হল expressionHashes হ্যাশের প্রতিটি হ্যাশের প্রথম 4 বাইট।
5. expressionHashPrefixes প্রতিটি expressionHashPrefix জন্য:
   1. স্থানীয় ক্যাশে expressionHashPrefix দেখুন।
   2. যদি ক্যাশে করা এন্ট্রি পাওয়া যায়:
      1. বর্তমান সময় তার মেয়াদ শেষ হওয়ার সময়ের চেয়ে বড় কিনা তা নির্ধারণ করুন।
      2. যদি এটি বড় হয়:
         1. স্থানীয় ক্যাশে থেকে পাওয়া ক্যাশে করা এন্ট্রি সরান।
         2. লুপ দিয়ে চালিয়ে যান।
      3. যদি এটি বড় না হয়:
         1. expressionHashPrefixes থেকে এই বিশেষ expressionHashPrefix সরান।
         2. expressionHashes মধ্যে সংশ্লিষ্ট পূর্ণ হ্যাশ ক্যাশে করা এন্ট্রিতে পাওয়া যায় কিনা তা পরীক্ষা করুন।
         3. পাওয়া গেলে, UNSAFE ফিরে যান।
         4. যদি না পাওয়া যায়, লুপ দিয়ে চালিয়ে যান।
   3. ক্যাশে করা এন্ট্রি পাওয়া না গেলে, লুপ দিয়ে চালিয়ে যান।
6. RPC SearchHashes বা REST পদ্ধতি hashes.search ব্যবহার করে Google Safe Browsing v5 সার্ভারে expressionHashPrefixes পাঠান। যদি একটি ত্রুটি ঘটে থাকে (নেটওয়ার্ক ত্রুটি, HTTP ত্রুটি, ইত্যাদি সহ), UNSURE ফেরত দিন। অন্যথায়, প্রতিক্রিয়াটি SB সার্ভার থেকে প্রাপ্ত response হতে দিন, যা হুমকির প্রকৃতি (সোশ্যাল ইঞ্জিনিয়ারিং, ম্যালওয়্যার, ইত্যাদি) এবং সেইসাথে ক্যাশের মেয়াদ শেষ হওয়ার সময়সীমার expiration শনাক্তকারী কিছু সহায়ক তথ্য সহ সম্পূর্ণ হ্যাশের একটি তালিকা।
7. response প্রতিটি fullHash জন্য:
   1. expiration সাথে স্থানীয় ক্যাশে fullHash ঢোকান।
8. response প্রতিটি fullHash জন্য:
   1. expressionHashes হ্যাশে fullHash খোঁজার ফলাফল হিসাবে isFound .
   2. যদি isFound মিথ্যা হয়, লুপ দিয়ে চালিয়ে যান।
   3. যদি isFound সত্য হয়, UNSAFE ফেরত দিন।
9. SAFE ফিরে যান।

ক্লায়েন্ট কখন সার্ভারে expressionHashPrefixes পাঠায় এই প্রোটোকলটি নির্দিষ্ট করে, এই প্রোটোকলটি উদ্দেশ্যমূলকভাবে সেগুলি কীভাবে পাঠাতে হয় তা নির্দিষ্ট করে না। উদাহরণস্বরূপ, ক্লায়েন্টের জন্য একক অনুরোধে সমস্ত expressionHashPrefixes পাঠানো গ্রহণযোগ্য, এবং ক্লায়েন্টের জন্য পৃথক অনুরোধে সার্ভারে expressionHashPrefixes প্রতিটি পৃথক প্রিফিক্স পাঠানোও গ্রহণযোগ্য (সম্ভবত সমান্তরালভাবে এগিয়ে যাওয়া)। expressionHashPrefixes হ্যাশ প্রিফিক্সে হ্যাশ উপসর্গের সাথে সম্পর্কহীন বা এলোমেলোভাবে তৈরি করা হ্যাশ উপসর্গগুলি ক্লায়েন্টের পক্ষে পাঠানোও গ্রহণযোগ্য, যতক্ষণ না একটি অনুরোধে পাঠানো হ্যাশ উপসর্গের সংখ্যা 30-এর বেশি না হয়।

লোকাল থ্রেট লিস্ট ইউআরএল চেক পদ্ধতি

এই পদ্ধতিটি ব্যবহার করা হয় যখন ক্লায়েন্ট অপারেশনের স্থানীয় তালিকা মোড বেছে নেয়। এটি ব্যবহার করা হয় যখন ক্লায়েন্ট উপরের RealTimeCheck পদ্ধতিটি UNSURE এর মান প্রদান করে।

এই পদ্ধতিটি একটি একক URL u নেয় এবং SAFE বা UNSAFE ফেরত দেয়।

1. expressions ইউআরএল u দ্বারা উত্পন্ন প্রত্যয়/প্রিফিক্স এক্সপ্রেশনের একটি তালিকা হতে দিন।
2. expressionHashes একটি তালিকা হতে দিন, যেখানে উপাদানগুলি প্রতিটি expressions এক্সপ্রেশনের SHA256 হ্যাশ।
3. expressionHashPrefixes একটি তালিকা করা যাক, যেখানে উপাদানগুলি হল expressionHashes হ্যাশের প্রতিটি হ্যাশের প্রথম 4 বাইট।
4. expressionHashPrefixes প্রতিটি expressionHashPrefix জন্য:
   1. স্থানীয় ক্যাশে expressionHashPrefix দেখুন।
   2. যদি ক্যাশে করা এন্ট্রি পাওয়া যায়:
      1. বর্তমান সময় তার মেয়াদ শেষ হওয়ার সময়ের চেয়ে বড় কিনা তা নির্ধারণ করুন।
      2. যদি এটি বড় হয়:
         1. স্থানীয় ক্যাশে থেকে পাওয়া ক্যাশে করা এন্ট্রি সরান।
         2. লুপ দিয়ে চালিয়ে যান।
      3. যদি এটি বড় না হয়:
         1. expressionHashPrefixes থেকে এই বিশেষ expressionHashPrefix সরান।
         2. expressionHashes মধ্যে সংশ্লিষ্ট পূর্ণ হ্যাশ ক্যাশে করা এন্ট্রিতে পাওয়া যায় কিনা তা পরীক্ষা করুন।
         3. পাওয়া গেলে, UNSAFE ফিরে যান।
         4. যদি না পাওয়া যায়, লুপ দিয়ে চালিয়ে যান।
   3. ক্যাশে করা এন্ট্রি পাওয়া না গেলে, লুপ দিয়ে চালিয়ে যান।
5. expressionHashPrefixes প্রতিটি expressionHashPrefix জন্য:
   1. স্থানীয় হুমকি তালিকা ডাটাবেসে expressionHashPrefix দেখুন।
   2. যদি expressionHashPrefix স্থানীয় হুমকি তালিকা ডাটাবেসে পাওয়া না যায় তবে expressionHashPrefixes থেকে এটি সরিয়ে দিন।
6. RPC SearchHashes বা REST পদ্ধতি hashes.search ব্যবহার করে Google Safe Browsing v5 সার্ভারে expressionHashPrefixes পাঠান। যদি একটি ত্রুটি ঘটে থাকে (নেটওয়ার্ক ত্রুটি, HTTP ত্রুটি, ইত্যাদি সহ), SAFE ফেরত দিন। অন্যথায়, প্রতিক্রিয়াটি SB সার্ভার থেকে প্রাপ্ত response হতে দিন, যা হুমকির প্রকৃতি (সোশ্যাল ইঞ্জিনিয়ারিং, ম্যালওয়্যার, ইত্যাদি) এবং সেইসাথে ক্যাশের মেয়াদ শেষ হওয়ার সময়সীমার expiration শনাক্তকারী কিছু সহায়ক তথ্য সহ সম্পূর্ণ হ্যাশের একটি তালিকা।
7. response প্রতিটি fullHash জন্য:
   1. expiration সাথে স্থানীয় ক্যাশে fullHash ঢোকান।
8. response প্রতিটি fullHash জন্য:
   1. expressionHashes হ্যাশে fullHash খোঁজার ফলাফল হিসাবে isFound .
   2. যদি isFound মিথ্যা হয়, লুপ দিয়ে চালিয়ে যান।
   3. যদি isFound সত্য হয়, UNSAFE ফেরত দিন।
9. SAFE ফিরে যান।

স্থানীয় ডাটাবেস ছাড়াই রিয়েল-টাইম ইউআরএল চেক পদ্ধতি

এই পদ্ধতিটি ব্যবহৃত হয় যখন ক্লায়েন্ট নো-স্টোরেজ রিয়েল-টাইম অপারেশন মোড বেছে নেয়।

এই পদ্ধতিটি একটি একক URL u নেয় এবং SAFE বা UNSAFE ফেরত দেয়।

1. expressions ইউআরএল u দ্বারা উত্পন্ন প্রত্যয়/প্রিফিক্স এক্সপ্রেশনের একটি তালিকা হতে দিন।
2. expressionHashes একটি তালিকা হতে দিন, যেখানে উপাদানগুলি প্রতিটি expressions এক্সপ্রেশনের SHA256 হ্যাশ।
3. expressionHashPrefixes একটি তালিকা করা যাক, যেখানে উপাদানগুলি হল expressionHashes হ্যাশের প্রতিটি হ্যাশের প্রথম 4 বাইট।
4. expressionHashPrefixes প্রতিটি expressionHashPrefix জন্য:
   1. স্থানীয় ক্যাশে expressionHashPrefix দেখুন।
   2. যদি ক্যাশে করা এন্ট্রি পাওয়া যায়:
      1. বর্তমান সময় তার মেয়াদ শেষ হওয়ার সময়ের চেয়ে বড় কিনা তা নির্ধারণ করুন।
      2. যদি এটি বড় হয়:
         1. স্থানীয় ক্যাশে থেকে পাওয়া ক্যাশে করা এন্ট্রি সরান।
         2. লুপ দিয়ে চালিয়ে যান।
      3. যদি এটি বড় না হয়:
         1. expressionHashPrefixes থেকে এই বিশেষ expressionHashPrefix সরান।
         2. expressionHashes মধ্যে সংশ্লিষ্ট পূর্ণ হ্যাশ ক্যাশে করা এন্ট্রিতে পাওয়া যায় কিনা তা পরীক্ষা করুন।
         3. পাওয়া গেলে, UNSAFE ফিরে যান।
         4. যদি না পাওয়া যায়, লুপ দিয়ে চালিয়ে যান।
   3. ক্যাশে করা এন্ট্রি পাওয়া না গেলে, লুপ দিয়ে চালিয়ে যান।
5. RPC SearchHashes বা REST পদ্ধতি hashes.search ব্যবহার করে Google Safe Browsing v5 সার্ভারে expressionHashPrefixes পাঠান। যদি একটি ত্রুটি ঘটে থাকে (নেটওয়ার্ক ত্রুটি, HTTP ত্রুটি, ইত্যাদি সহ), SAFE ফেরত দিন। অন্যথায়, প্রতিক্রিয়াটি SB সার্ভার থেকে প্রাপ্ত response হতে দিন, যা হুমকির প্রকৃতি (সোশ্যাল ইঞ্জিনিয়ারিং, ম্যালওয়্যার, ইত্যাদি) এবং সেইসাথে ক্যাশের মেয়াদ শেষ হওয়ার সময়সীমার expiration শনাক্তকারী কিছু সহায়ক তথ্য সহ সম্পূর্ণ হ্যাশের একটি তালিকা।
6. response প্রতিটি fullHash জন্য:
   1. expiration সাথে স্থানীয় ক্যাশে fullHash ঢোকান।
7. response প্রতিটি fullHash জন্য:
   1. expressionHashes হ্যাশে fullHash খোঁজার ফলাফল হিসাবে isFound .
   2. যদি isFound মিথ্যা হয়, লুপ দিয়ে চালিয়ে যান।
   3. যদি isFound সত্য হয়, UNSAFE ফেরত দিন।
8. SAFE ফিরে যান।

রিয়েল-টাইম ইউআরএল চেক পদ্ধতির মতোই, এই পদ্ধতিটি সার্ভারে হ্যাশ উপসর্গগুলি কীভাবে পাঠাতে হয় তা নির্দিষ্ট করে না। উদাহরণস্বরূপ, ক্লায়েন্টের জন্য একক অনুরোধে সমস্ত expressionHashPrefixes পাঠানো গ্রহণযোগ্য, এবং ক্লায়েন্টের জন্য পৃথক অনুরোধে সার্ভারে expressionHashPrefixes প্রতিটি পৃথক প্রিফিক্স পাঠানোও গ্রহণযোগ্য (সম্ভবত সমান্তরালভাবে এগিয়ে যাওয়া)। expressionHashPrefixes হ্যাশ প্রিফিক্সে হ্যাশ উপসর্গের সাথে সম্পর্কহীন বা এলোমেলোভাবে তৈরি করা হ্যাশ উপসর্গগুলি ক্লায়েন্টের পক্ষে পাঠানোও গ্রহণযোগ্য, যতক্ষণ না একটি অনুরোধে পাঠানো হ্যাশ উপসর্গের সংখ্যা 30-এর বেশি না হয়।

স্থানীয় ডাটাবেস রক্ষণাবেক্ষণ

Google নিরাপদ ব্রাউজিং v5 আশা করে যে ক্লায়েন্ট একটি স্থানীয় ডাটাবেস বজায় রাখবে, যখন ক্লায়েন্ট নো-স্টোরেজ রিয়েল-টাইম মোড বেছে নেয়। এই স্থানীয় ডাটাবেসের বিন্যাস এবং স্টোরেজ ক্লায়েন্টের উপর নির্ভর করে। এই স্থানীয় ডাটাবেসের বিষয়বস্তুকে ধারণাগতভাবে ফাইল হিসাবে বিভিন্ন তালিকা সমন্বিত একটি ফোল্ডার হিসাবে ভাবা যেতে পারে এবং এই ফাইলগুলির বিষয়বস্তু হল SHA256 হ্যাশ বা হ্যাশ উপসর্গ।

ডাটাবেস আপডেট

ক্লায়েন্ট নিয়মিতভাবে ডাটাবেস আপডেট করার জন্য hashList.get পদ্ধতি বা hashLists.batchGet পদ্ধতিতে কল করবে। যেহেতু সাধারণ ক্লায়েন্ট একবারে একাধিক তালিকা আপডেট করতে চাইবে, তাই hashLists.batchGet পদ্ধতি ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।

তালিকাগুলি তাদের স্বতন্ত্র নামের দ্বারা চিহ্নিত করা হয়। নামগুলো ছোট ASCII স্ট্রিং কয়েক অক্ষর লম্বা।

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

একবার একটি তালিকার জন্য একটি নাম বেছে নেওয়া হলে, এটির নাম পরিবর্তন করা হবে না। তদ্ব্যতীত, একবার একটি তালিকা উপস্থিত হলে, এটি কখনই সরানো হবে না (যদি তালিকাটি আর কার্যকর না হয় তবে এটি খালি হয়ে যাবে তবে বিদ্যমান থাকবে)। অতএব, Google সেফ ব্রাউজিং ক্লায়েন্ট কোডে এই নামগুলিকে হার্ড কোড করা উপযুক্ত৷

hashList.get পদ্ধতি এবং hashLists.batchGet পদ্ধতি উভয়ই ক্রমবর্ধমান আপডেট সমর্থন করে। ক্রমবর্ধমান আপডেট ব্যবহার করা ব্যান্ডউইথ সংরক্ষণ করে এবং কর্মক্ষমতা উন্নত করে। ক্রমবর্ধমান আপডেটগুলি তালিকার ক্লায়েন্টের সংস্করণ এবং তালিকার সর্বশেষ সংস্করণের মধ্যে একটি ডেল্টা প্রদান করে কাজ করে। (যদি একটি ক্লায়েন্ট নতুনভাবে স্থাপন করা হয় এবং কোন সংস্করণ উপলব্ধ না থাকে, তাহলে একটি সম্পূর্ণ আপডেট উপলব্ধ।) ক্রমবর্ধমান আপডেটে অপসারণ সূচক এবং সংযোজন রয়েছে। ক্লায়েন্ট প্রথমে তার স্থানীয় ডাটাবেস থেকে নির্দিষ্ট সূচকে এন্ট্রিগুলি সরিয়ে ফেলবে এবং তারপরে সংযোজনগুলি প্রয়োগ করবে বলে আশা করা হয়।

অবশেষে, দুর্নীতি প্রতিরোধ করার জন্য, ক্লায়েন্টকে সার্ভার দ্বারা প্রদত্ত চেকসামের বিপরীতে সংরক্ষিত ডেটা পরীক্ষা করা উচিত। যখনই চেকসাম মেলে না, ক্লায়েন্টের একটি সম্পূর্ণ আপডেট করা উচিত।

তালিকা বিষয়বস্তু ডিকোডিং

ডিকোডিং হ্যাশ এবং হ্যাশ উপসর্গ

আকার কমাতে একটি বিশেষ এনকোডিং ব্যবহার করে সমস্ত তালিকা বিতরণ করা হয়। এই এনকোডিংটি এই স্বীকৃতি দিয়ে কাজ করে যে Google নিরাপদ ব্রাউজিং তালিকায় ধারণাগতভাবে, হ্যাশ বা হ্যাশ উপসর্গের একটি সেট রয়েছে, যা পরিসংখ্যানগতভাবে র্যান্ডম পূর্ণসংখ্যা থেকে আলাদা করা যায় না। যদি আমরা এই পূর্ণসংখ্যাগুলিকে বাছাই করি এবং তাদের সন্নিহিত পার্থক্য গ্রহণ করি, তাহলে এই ধরনের সন্নিহিত পার্থক্যটি এক অর্থে "ছোট" হবে বলে আশা করা হচ্ছে। Golomb-Rice এনকোডিং তখন এই ক্ষুদ্রতাকে কাজে লাগায়।

ধরুন যে তিনটি হোস্ট-প্রত্যয় পাথ-প্রিফিক্স এক্সপ্রেশন, যথা a.example.com/ , b.example.com/ , এবং y.example.com/ , 4-বাইট হ্যাশ উপসর্গ ব্যবহার করে প্রেরণ করা হবে। আরও ধরুন যে রাইস প্যারামিটার, কে দ্বারা চিহ্নিত করা হয়েছে, 30 হিসাবে বেছে নেওয়া হয়েছে। সার্ভারটি এই স্ট্রিংগুলির জন্য সম্পূর্ণ হ্যাশ গণনা করে শুরু করবে, যা যথাক্রমে:

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"
}

ক্লায়েন্ট হ্যাশ উপসর্গগুলিকে ডিকোড করতে বিপরীতভাবে উপরের ধাপগুলি অনুসরণ করে। v4 এর বিপরীতে, হ্যাশ প্রিফিক্স পূর্ণসংখ্যাগুলিকে বড় এন্ডিয়ান হিসাবে ব্যাখ্যা করার কারণে শেষে একটি বাইট অদলবদল করার দরকার নেই।

ডিকোডিং অপসারণ সূচক

অপসারণ সূচকগুলি 32-বিট পূর্ণসংখ্যা ব্যবহার করে উপরের মতো ঠিক একই কৌশল ব্যবহার করে এনকোড করা হয়। অপসারণ সূচকগুলির এনকোডিং এবং ডিকোডিং v4 এবং v5 এর মধ্যে পরিবর্তিত হয়নি।

উপলব্ধ তালিকা

নিম্নলিখিত তালিকাগুলি v5alpha1-এ ব্যবহারের জন্য সুপারিশ করা হয়:

তালিকার নাম	সংশ্লিষ্ট v4 ThreatType Enum	বর্ণনা
gc	কোনোটিই নয়	এই তালিকাটি একটি বিশ্বব্যাপী ক্যাশে তালিকা। এটি একটি বিশেষ তালিকা যা শুধুমাত্র অপারেশনের রিয়েল-টাইম মোডে ব্যবহৃত হয়।
se	SOCIAL_ENGINEERING	এই তালিকায় SOCIAL_ENGINEERING হুমকি ধরনের হুমকি রয়েছে৷
mw	MALWARE	এই তালিকায় ডেস্কটপ প্ল্যাটফর্মের জন্য ম্যালওয়্যার হুমকি ধরনের হুমকি রয়েছে।
uws	UNWANTED_SOFTWARE	এই তালিকায় ডেস্কটপ প্ল্যাটফর্মের জন্য UNWANTED_SOFTWARE হুমকি ধরনের হুমকি রয়েছে।
uwsa	UNWANTED_SOFTWARE	এই তালিকায় Android প্ল্যাটফর্মগুলির জন্য UNWANTED_SOFTWARE হুমকি ধরনের হুমকি রয়েছে৷
pha	POTENTIALLY_HARMFUL_APPLICATION	এই তালিকায় Android প্ল্যাটফর্মের জন্য POTENTIALLY_HARMFUL_APPLICATION হুমকি ধরনের হুমকি রয়েছে।

অতিরিক্ত তালিকা পরবর্তী তারিখে উপলব্ধ হবে, যে সময়ে উপরের টেবিলটি প্রসারিত হবে।

ক্লায়েন্টকে উপরের কিছু বা সমস্ত তালিকা পুনরুদ্ধার করতে এবং তারপরে ক্লায়েন্টকে প্রক্সি সার্ভারের সাথে যোগাযোগ করতে একটি ক্যাশিং প্রক্সি সার্ভার পরিচালনা করার অনুমতি দেওয়া হয়। যদি এটি বাস্তবায়িত হয়, আমরা একটি ছোট ক্যাশে সময়কাল সুপারিশ করি যেমন পাঁচ মিনিট; ভবিষ্যতে এই ক্যাশে সময়কাল স্ট্যান্ডার্ড Cache-Control HTTP হেডার ব্যবহার করে যোগাযোগ করা যেতে পারে।

আপডেট ফ্রিকোয়েন্সি

ক্লায়েন্টকে minimum_wait_duration ফিল্ডে সার্ভারের প্রত্যাবর্তিত মান পরিদর্শন করা উচিত এবং ডাটাবেসের পরবর্তী আপডেটের সময়সূচী করতে এটি ব্যবহার করা উচিত। এই মানটি সম্ভবত শূন্য (ক্ষেত্রটি minimum_wait_duration সম্পূর্ণভাবে অনুপস্থিত), এই ক্ষেত্রে ক্লায়েন্টকে অবিলম্বে অন্য আপডেট করতে হবে।

উদাহরণ অনুরোধ

এই বিভাগে Google নিরাপদ ব্রাউজিং অ্যাক্সেস করতে সরাসরি HTTP API ব্যবহার করার কিছু উদাহরণ নথিভুক্ত করা হয়েছে। এটি সাধারণত একটি জেনারেটেড ল্যাঙ্গুয়েজ বাইন্ডিং ব্যবহার করার পরামর্শ দেওয়া হয় কারণ এটি স্বয়ংক্রিয়ভাবে এনকোডিং এবং ডিকোডিং একটি সুবিধাজনক উপায়ে পরিচালনা করবে। যে বাঁধাই জন্য ডকুমেন্টেশন পড়ুন দয়া করে.

এখানে hashes.search পদ্ধতি ব্যবহার করে একটি উদাহরণ HTTP অনুরোধ:

GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ

রেসপন্স বডি হল একটি প্রোটোকল-বাফার ফরম্যাট করা পেলোড যা আপনি ডিকোড করতে পারেন।

এখানে hashLists.batchGet পদ্ধতি ব্যবহার করে HTTP অনুরোধের একটি উদাহরণ রয়েছে:

GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw

রেসপন্স বডি হল, আবার, একটি প্রোটোকল-বাফার ফরম্যাট করা পেলোড যা আপনি ডিকোড করতে পারেন।

মাইগ্রেশন গাইড

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

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

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

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

1. সম্পূর্ণভাবে v4 ClientInfo অবজেক্ট সরান। একটি ডেডিকেটেড ফিল্ড ব্যবহার করে ক্লায়েন্টের শনাক্তকরণ সরবরাহ করার পরিবর্তে, শুধুমাত্র সুপরিচিত User-Agent হেডার ব্যবহার করুন। যদিও এই শিরোনামে ক্লায়েন্ট সনাক্তকরণ সরবরাহের জন্য কোনও নির্ধারিত ফর্ম্যাট নেই, আমরা কেবলমাত্র মূল ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সংস্করণ সহ একটি স্পেস চরিত্র বা স্ল্যাশ চরিত্র দ্বারা পৃথক করা পরামর্শ দিই।
2. প্রতিটি ভি 4 ListUpdateRequest অবজেক্টের জন্য:
   • উপরের সারণীতে সংশ্লিষ্ট ভি 5 তালিকার নামটি সন্ধান করুন এবং ভি 5 অনুরোধে সেই নাম সরবরাহ করুন।
   • threat_entry_type বা platform_type মতো অপ্রয়োজনীয় ক্ষেত্রগুলি সরান।
   • ভি 4 এর state ক্ষেত্রটি ভি 5 versions ক্ষেত্রের সাথে সরাসরি সামঞ্জস্যপূর্ণ। একই বাইট স্ট্রিং যা ভি 4 -তে state ক্ষেত্রটি ব্যবহার করে সার্ভারে প্রেরণ করা হবে কেবল versions ক্ষেত্রটি ব্যবহার করে ভি 5 এ প্রেরণ করা যেতে পারে।
   • ভি 4 সীমাবদ্ধতার জন্য, ভি 5 SizeConstraints নামে একটি সরল সংস্করণ ব্যবহার করে। region মতো অতিরিক্ত ক্ষেত্রগুলি বাদ দেওয়া উচিত।

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

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

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

ভি 4 -তে, কেউ পূর্ণ হ্যাশ পেতে ফুলহ্যাশ.ফাইন্ড পদ্ধতি ব্যবহার করবে। ভি 5 এর সমতুল্য পদ্ধতি হ'ল হ্যাশস.স অনুসন্ধান পদ্ধতি ।

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

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

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

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