Migration From V4

یکی از پیشرفت‌های قابل توجه Google Safe Browsing نسخه 5 نسبت به نسخه 4 (به طور خاص، API به‌روزرسانی v4 ) تازگی و پوشش داده است. از آنجایی که حفاظت به شدت به پایگاه داده محلی نگهداری شده توسط سرویس گیرنده بستگی دارد، تاخیر و اندازه به روز رسانی پایگاه داده محلی عامل اصلی حفاظت از دست رفته است. در نسخه 4، مشتری معمولی 20 تا 50 دقیقه طول می کشد تا به روزترین نسخه لیست تهدیدات را به دست آورد. متأسفانه، حملات فیشینگ به سرعت گسترش می‌یابد: تا سال 2021، 60 درصد سایت‌هایی که حملات را انجام می‌دهند کمتر از 10 دقیقه عمر می‌کنند. تجزیه و تحلیل ما نشان می دهد که حدود 25 تا 30 درصد از محافظت از دست رفته فیشینگ به دلیل چنین بیاتی داده ها است. علاوه بر این، برخی از دستگاه‌ها برای مدیریت کل لیست‌های تهدید مرور ایمن Google مجهز نیستند، که به مرور زمان بزرگ‌تر می‌شود.

اگر در حال حاضر از v4 Update API استفاده می‌کنید، یک مسیر یکپارچه از نسخه 4 به نسخه 5 بدون نیاز به تنظیم مجدد یا پاک کردن پایگاه داده محلی وجود دارد. این بخش نحوه انجام آن را مستند می کند.

تبدیل به‌روزرسانی‌های فهرست

بر خلاف V4، که در آن لیست ها با چند نوع تهدید، نوع پلت فرم، نوع ورود تهدید شناسایی می شوند، در V5 لیست ها به سادگی با نام شناسایی می شوند. هنگامی که چندین لیست v5 می توانند یک نوع تهدید را به اشتراک بگذارند، این انعطاف پذیری را فراهم می کند. انواع پلت فرم و انواع ورود تهدید در نسخه 5 حذف شده اند.

در نسخه 4، برای دانلود لیست ها از متد gefListUpdates.fetch استفاده می شود. در نسخه 5، می توان به روش hashLists.batchGet سوئیچ کرد.

تغییرات زیر باید در درخواست ایجاد شود:

  1. شی v4 ClientInfo را به طور کامل حذف کنید. به جای ارائه شناسه مشتری با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. در حالی که هیچ فرمت مشخصی برای ارائه شناسه مشتری در این هدر وجود ندارد، پیشنهاد می کنیم به سادگی شناسه مشتری اصلی و نسخه مشتری را که با یک نویسه فاصله یا یک کاراکتر اسلش از هم جدا شده اند، اضافه کنید.
  2. برای هر شیء v4 ListUpdateRequest : * نام لیست v5 مربوطه را در جدول بالا جستجو کنید و آن نام را در درخواست v5 وارد کنید.
    • فیلدهای غیرضروری مانند threat_entry_type یا platform_type را حذف کنید.
    • فیلد state در v4 مستقیماً با قسمت versions v5 سازگار است. همان رشته بایتی که با استفاده از فیلد state در v4 به سرور ارسال می شود، می تواند به سادگی با استفاده از فیلد versions در v5 ارسال شود.
    • برای محدودیت های v4، v5 از یک نسخه ساده شده به نام SizeConstraints استفاده می کند. فیلدهای اضافی مانند region باید حذف شوند.

تغییرات زیر باید در پاسخ ایجاد شود:

  1. v4 enum ResponseType به سادگی با یک فیلد بولی به نام partial_update جایگزین می شود.
  2. اکنون می‌توان فیلد minimum_wait_duration را صفر یا حذف کرد. اگر چنین باشد، از مشتری درخواست می شود که فوراً درخواست دیگری ارائه دهد. این تنها زمانی اتفاق می‌افتد که مشتری در SizeConstraints محدودیت کوچک‌تری را برای حداکثر اندازه به‌روزرسانی نسبت به حداکثر اندازه پایگاه داده تعیین کند.
  3. الگوریتم رمزگشایی Rice برای اعداد صحیح 32 بیتی باید تنظیم شود. تفاوت در این است که داده های کدگذاری شده با endianness متفاوت کدگذاری می شوند. در هر دو نسخه 4 و 5، پیشوندهای هش 32 بیتی به صورت واژگانی مرتب شده اند. اما در v4، آن پیشوندها هنگام مرتب‌سازی به‌عنوان اندیان کوچک در نظر گرفته می‌شوند، در حالی که در v5 آن پیشوندها هنگام مرتب‌سازی به عنوان اندیان بزرگ در نظر گرفته می‌شوند. این بدان معناست که مشتری نیازی به مرتب سازی ندارد، زیرا مرتب سازی واژگانی با مرتب سازی عددی با اندیان بزرگ یکسان است. نمونه‌ای از این نوع در اجرای Chromium نسخه 4 را می‌توانید در اینجا پیدا کنید. چنین مرتب سازی را می توان حذف کرد.
  4. الگوریتم رمزگشایی Rice باید برای سایر طول های هش نیز پیاده سازی شود.

تبدیل جستجوهای هش

در نسخه 4، از روش fullHashes.find برای بدست آوردن هش کامل استفاده می شود. روش معادل در v5 روش hash.search است.

تغییرات زیر باید در درخواست ایجاد شود:

  1. ساختار کد را طوری تنظیم کنید که فقط پیشوندهای هش که دقیقاً 4 بایت طول دارند ارسال کند.
  2. اشیاء v4 ClientInfo را به طور کامل حذف کنید. به جای ارائه شناسه مشتری با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. در حالی که هیچ فرمت مشخصی برای ارائه شناسه مشتری در این هدر وجود ندارد، پیشنهاد می کنیم به سادگی شناسه مشتری اصلی و نسخه مشتری را که با یک نویسه فاصله یا یک کاراکتر اسلش از هم جدا شده اند، اضافه کنید.
  3. قسمت client_states را حذف کنید. دیگر لازم نیست.
  4. دیگر نیازی به وارد کردن threat_types و فیلدهای مشابه نیست.

تغییرات زیر باید در پاسخ ایجاد شود:

  1. قسمت minimum_wait_duration حذف شده است. مشتری همیشه می تواند بر اساس نیاز درخواست جدیدی صادر کند.
  2. شی v4 ThreatMatch به شی FullHash ساده شده است.
  3. ذخیره سازی به یک مدت زمان کش ساده شده است. رویه های بالا را برای تعامل با حافظه پنهان ببینید.