یکی از پیشرفت‌های قابل توجه Google Safe Browsing v5 نسبت به نسخه ۴ (به طور خاص، API به‌روزرسانی v4 ) تازگی و پوشش داده‌ها است. از آنجایی که محافظت به شدت به پایگاه داده محلی نگهداری شده توسط کلاینت بستگی دارد، تأخیر و اندازه به‌روزرسانی پایگاه داده محلی عامل اصلی از دست رفتن محافظت است. در نسخه ۴، کلاینت معمولی ۲۰ تا ۵۰ دقیقه طول می‌کشد تا به‌روزترین نسخه فهرست‌های تهدید را دریافت کند. متأسفانه، حملات فیشینگ به سرعت گسترش می‌یابند: از سال ۲۰۲۱، ۶۰٪ از سایت‌هایی که حملات را انجام می‌دهند، کمتر از ۱۰ دقیقه زنده می‌مانند. تجزیه و تحلیل ما نشان می‌دهد که حدود ۲۵ تا ۳۰٪ از از دست رفتن محافظت فیشینگ به دلیل چنین قدیمی بودن داده‌ها است. علاوه بر این، برخی از دستگاه‌ها برای مدیریت کل فهرست‌های تهدید Google Safe Browsing مجهز نیستند، که با گذشت زمان همچنان بزرگتر می‌شود.
اگر در حال حاضر از API به‌روزرسانی نسخه ۴ استفاده می‌کنید، یک مسیر مهاجرت یکپارچه از نسخه ۴ به نسخه ۵ بدون نیاز به تنظیم مجدد یا پاک کردن پایگاه داده محلی وجود دارد. این بخش نحوه انجام این کار را مستند می‌کند.
تبدیل به‌روزرسانی‌های لیست
برخلاف نسخه ۴ که لیست‌ها با تاپل نوع تهدید، نوع پلتفرم و نوع ورودی تهدید شناسایی می‌شوند، در نسخه ۵ لیست‌ها به سادگی با نام شناسایی می‌شوند. این امر انعطاف‌پذیری را در زمانی که چندین لیست نسخه ۵ می‌توانند نوع تهدید یکسانی را به اشتراک بگذارند، فراهم می‌کند. انواع پلتفرم و انواع ورودی تهدید در نسخه ۵ حذف شده‌اند.
در نسخه ۴، می‌توان از متد threatListUpdates.fetch برای دانلود لیست‌ها استفاده کرد. در نسخه ۵، می‌توان به متد hashLists.batchGet سوئیچ کرد.
تغییرات زیر باید در درخواست اعمال شود:
- شیء
ClientInfoنسخه ۴ را به طور کامل حذف کنید. به جای ارائه شناسه کلاینت با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. اگرچه هیچ قالب از پیش تعیین‌شده‌ای برای ارائه شناسه کلاینت در این هدر وجود ندارد، پیشنهاد می‌کنیم به سادگی شناسه کلاینت اصلی و نسخه کلاینت را که با یک کاراکتر فاصله یا یک کاراکتر اسلش از هم جدا شده‌اند، وارد کنید. - برای هر شیء
ListUpdateRequestنسخه ۴ : * نام لیست نسخه ۵ مربوطه را از لیست‌های موجود جستجو کنید و آن نام را در درخواست نسخه ۵ ارائه دهید.- فیلدهای غیرضروری مانند
threat_entry_typeیاplatform_typeرا حذف کنید. - فیلد
stateدر نسخه ۴ مستقیماً با فیلدversionsنسخه ۵ سازگار است. همان رشته بایتی که با استفاده از فیلدstateدر نسخه ۴ به سرور ارسال می‌شد، می‌تواند به سادگی در نسخه ۵ با استفاده از فیلدversionsارسال شود. - برای محدودیت‌های نسخه ۴، نسخه ۵ از یک نسخه ساده‌شده به نام
SizeConstraintsاستفاده می‌کند. فیلدهای اضافی مانندregionباید حذف شوند.
- فیلدهای غیرضروری مانند
تغییرات زیر باید در پاسخنامه اعمال شود:
- متغیر شمارشی v4 به نام
ResponseTypeبه سادگی با یک فیلد بولی به نامpartial_updateجایگزین می‌شود. - فیلد
minimum_wait_durationاکنون می‌تواند صفر یا حذف شود. در این صورت، از کلاینت درخواست می‌شود که فوراً درخواست دیگری ارسال کند. این تنها زمانی اتفاق می‌افتد که کلاینت درSizeConstraintsمحدودیتی کوچکتر از حداکثر اندازه به‌روزرسانی نسبت به حداکثر اندازه پایگاه داده تعیین کند. - منطق رمزگشایی هش‌های کدگذاری شده‌ی رایس-گولومب نیاز به دو تنظیم اصلی دارد:
- Endianness و مرتب‌سازی: در نسخه ۴، هش‌های برگردانده شده به صورت مقادیر little-endian مرتب‌سازی می‌شدند. در نسخه ۵، آنها به صورت مقادیر big-endian در نظر گرفته می‌شوند. از آنجا که مرتب‌سازی لغوی رشته‌های بایت معادل مرتب‌سازی عددی مقادیر big-endian است، کلاینت‌ها دیگر نیازی به انجام مرحله مرتب‌سازی خاصی ندارند. مرتب‌سازی little-endian سفارشی، مانند آنچه در پیاده‌سازی Chromium نسخه ۴ وجود دارد، در صورت پیاده‌سازی قبلی، قابل حذف است.
- طول‌های هش متغیر: الگوریتم رمزگشایی باید به‌روزرسانی شود تا از طول‌های هش مختلفی که می‌توانند در فیلد
HashList.compressed_additionsبرگردانده شوند، پشتیبانی کند، نه فقط طول هش چهار بایتی که در نسخه ۴ استفاده می‌شود. طول هش‌های برگردانده شده در پاسخ را می‌توان بر اساسHashList.metadata.hash_lengthبرگردانده شده ازhashLists.listتعیین کرد. از طرف دیگر، نامگذاری لیست هش درخواستی، اندازه‌های هش مورد انتظار برگردانده شده از لیست را نیز نشان می‌دهد. برای جزئیات بیشتر در مورد لیست‌های هش، به صفحه پایگاه داده محلی مراجعه کنید.
تبدیل جستجوهای هش
در نسخه ۴، می‌توان از متد fullHashes.find برای دریافت هش‌های کامل استفاده کرد. متد معادل آن در نسخه ۵، متد hashes.search است.
تغییرات زیر باید در درخواست اعمال شود:
- کد را طوری ساختار دهید که فقط پیشوندهای هش با طول دقیقاً ۴ بایت ارسال شوند.
- اشیاء
ClientInfoنسخه ۴ را به طور کلی حذف کنید. به جای ارائه شناسه کلاینت با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. در حالی که هیچ فرمت از پیش تعیین‌شده‌ای برای ارائه شناسه کلاینت در این هدر وجود ندارد، پیشنهاد می‌کنیم به سادگی شناسه کلاینت اصلی و نسخه کلاینت را که با یک کاراکتر فاصله یا یک کاراکتر اسلش از هم جدا شده‌اند، وارد کنید. - فیلد
client_statesرا حذف کنید. دیگر نیازی به آن نیست. - دیگر نیازی به وارد کردن
threat_typesو فیلدهای مشابه نیست.
تغییرات زیر باید در پاسخنامه اعمال شود:
- فیلد
minimum_wait_durationحذف شده است. کلاینت همیشه می‌تواند در صورت نیاز درخواست جدیدی ارسال کند. - شیء
ThreatMatchنسخه ۴ به شیءFullHashساده‌سازی شده است. - ذخیره سازی به یک دوره زمانی ذخیره سازی ساده شده است. برای تعامل با حافظه پنهان، به رویه‌های فوق مراجعه کنید.