Overview

مقدمة

ملاحظة: لا تزال هذه المستندات قيد التطوير حاليًا. ومن المتوقّع حدوث تحسينات في المستقبل القريب.

يُعد الإصدار 5 من ميزة "التصفّح الآمن من Google" متطوّرًا للإصدار 4 من "التصفّح الآمن من Google". والتغييران الرئيسيان اللذان تم إجراؤهما في الإصدار 5 هما حداثة البيانات وخصوصية عنوان IP. بالإضافة إلى ذلك، تم تحسين مساحة عرض واجهة برمجة التطبيقات لزيادة المرونة والكفاءة وتقليل تكدس البيانات. بالإضافة إلى ذلك، تم تصميم الإصدار 5 من "التصفّح الآمن من Google" لتسهيل عملية الانتقال من الإصدار 4.

في الوقت الحالي، توفّر Google الإصدارَين 4 و5 وكلَيهما جاهزان للإصدار العلني. يمكنك استخدام الإصدار 4 أو 5. لم نعلن عن تاريخ إيقاف الإصدار 4. وفي حال إجراء ذلك، سنقدّم إشعارًا بمدة عام واحد على الأقل. ستصف هذه الصفحة الإصدار 5 بالإضافة إلى دليل لنقل البيانات من الإصدار 4 إلى 5، وتظل مستندات الإصدار 4 الكاملة متوفّرة.

حداثة البيانات

يُعدّ حداثة البيانات وتغطية البيانات أحد التحسينات المهمة في الإصدار 5 من "التصفّح الآمن من Google" مقارنةً بالإصدار 4 (على وجه التحديد، واجهة برمجة التطبيقات v4 Update API). ونظرًا لأن الحماية تعتمد بشكل كبير على قاعدة البيانات المحلية التي يحتفظ بها العميل، فإن تأخير تحديث قاعدة البيانات المحلية وحجمه هما المساهم الرئيسي في الحماية المفقودة. وفي الإصدار 4، يستغرق العميل العادي من 20 إلى 50 دقيقة للحصول على أحدث إصدار من قوائم التهديدات. للأسف، انتشرت هجمات التصيّد الاحتيالي بسرعة: اعتبارًا من عام 2021، بدأت 60% من المواقع الإلكترونية التي ترسِل هجمات مباشرة أقل من 10 دقائق. ويظهِر تحليلنا أنّ ما يقرب من %25 إلى %30 من حالات فقدان الحماية من التصيّد الاحتيالي تعود إلى بقِدَ البيانات. بالإضافة إلى ذلك، بعض الأجهزة غير مجهّزة لإدارة قوائم التهديدات في ميزة "التصفّح الآمن من Google" بالكامل، والتي يتزايد عددها بمرور الوقت.

ونقدّم في الإصدار 5 وضعًا للعمل يُعرف باسم الحماية في الوقت الفعلي. يؤدي هذا إلى التحايل على مشكلة تلف البيانات المذكورة أعلاه. أما في الإصدار 4، فيجب أن ينزّل العملاء قاعدة بيانات محلّية ويحتفظون بها، وأن ينفّذوا عمليات التحقّق من قوائم التهديدات التي تم تنزيلها على الجهاز، ثم يطلبون تنزيل التجزئة الكاملة عند حدوث مطابقة جزئية للبادئة. في الإصدار 5، من المفترض أن يواصل العملاء تنزيل قاعدة بيانات محلية تتضمّن قوائم التهديدات والاحتفاظ بها، ولكن من المتوقّع الآن أن ينزّل العملاء قائمة بالمواقع الإلكترونية التي يُحتمل أن تكون حميدة (يُطلق عليها ذاكرة التخزين المؤقت العالمية)، وإجراء فحص محلي لذاكرة التخزين المؤقت العالمية هذه وفحص قائمة التهديدات على الجهاز. وأخيرًا، عندما تكون هناك مطابقة جزئية للبادئة لقوائم التهديدات أو في حال عدم تطابق بادئة في ذاكرة التخزين المؤقت العالمية، يمكنهم تنفيذ طلب لتنزيل علامات التجزئة بالكامل. (لمزيد من التفاصيل عن المعالجة المحلية التي يطلبها العميل، يُرجى الاطّلاع على الإجراء المقدم أدناه). ويمثّل ذلك تحولاً من "السماح تلقائيًا" إلى "مفعَّل تلقائيًا"، ما يساعد في تحسين الحماية في ضوء الانتشار الأسرع للتهديدات على الويب. بعبارة أخرى، هذا بروتوكول مصمّم لتوفير حماية في الوقت الفعلي تقريبًا، ونهدف إلى مساعدة العملاء في الاستفادة من أحدث بيانات "التصفّح الآمن من Google".

خصوصية عنوان IP

لا تعالج ميزة "التصفّح الآمن من Google" (الإصدار 4 أو 5) أي معلومات مرتبطة بهوية المستخدم أثناء تقديم الطلبات. ويتم تجاهل ملفات تعريف الارتباط، في حال إرسالها. وتعرف Google عناوين IP الأصلية للطلبات، إلا أن Google لا تستخدم عناوين IP إلا من أجل الاحتياجات الأساسية للشبكات (أي لإرسال الردود) ولأغراض مكافحة الحرمان من الخدمات.

بالتزامن مع الإصدار 5، نقدّم واجهة برمجة تطبيقات مصاحبة تُعرف باسم "واجهة برمجة تطبيقات مدخل بروتوكول HTTP في التصفح الآمن". يستخدم هذا الإجراء بروتوكول HTTP الآمن لإخفاء عناوين IP الخاصة بالمستخدمين النهائيين من Google. وهي تعمل من خلال الاستعانة بجهة خارجية غير مترابطة لمعالجة النسخة المشفَّرة من طلب المستخدم، ثم إعادة توجيهها إلى Google. وبالتالي، يمكن للجهة الخارجية الوصول فقط إلى عناوين IP، وبإمكان Google الوصول إلى محتوى الطلب فقط. تدير الجهة الخارجية بروتوكول Oblivious HTTP Relay (مثل هذه الخدمة من Fastly)، وتدير Google بوابة بروتوكول Oblivious HTTP. هذه واجهة برمجة تطبيقات مصاحبة اختيارية. وعند استخدامه مع ميزة "التصفّح الآمن من Google"، لن يتمّ بعد ذلك إرسال عناوين IP الخاصة بالمستخدمين إلى Google.

الاستخدام المناسب

الاستخدام المسموح به

إنّ واجهة برمجة التطبيقات للتصفّح الآمن مخصّصة للاستخدام غير التجاري فقط (أي "ليست للبيع أو لأغراض تحقيق الأرباح"). إذا كنت بحاجة إلى حلّ لأغراض تجارية، يُرجى الرجوع إلى مقالة مخاطر الويب.

التسعير

تتوفر جميع واجهات برمجة التطبيقات للتصفح الآمن من Google بدون أي تكلفة.

الحصص

يتم تخصيص حصة استخدام تلقائية للمطوّرين عند تفعيل واجهة برمجة تطبيقات "التصفّح الآمن". يمكن الاطّلاع على التخصيص والاستخدام الحاليَين في Google Play Console. إذا كنت تتوقع استخدام أكثر من الحصة المخصّصة لك حاليًا، يمكنك طلب حصة إضافية من واجهة حصة المطوّرين. إنّنا نراجع هذه الطلبات ونشترط التواصل معك عند التقدّم بطلب للحصول على حصة أكبر للتأكّد من أنّ مدى توفّر خدمتنا يلبي احتياجات جميع المستخدمين.

عناوين URL المناسبة

تم تصميم ميزة "التصفّح الآمن من Google" للتعامل مع عناوين URL التي سيتم عرضها في شريط عناوين المتصفّح. ولم يتم تصميمه للاستخدام في التحقق من الموارد الفرعية (مثل JavaScript أو صورة تتم الإشارة إليها من خلال ملف HTML أو عنوان URL WebSocket بدأته JavaScript). يجب عدم التحقّق من عناوين URL الخاصة بالموارد الفرعية من خلال ميزة "التصفّح الآمن من Google".

إذا نتج عن زيارة عنوان URL إعادة توجيه (مثل HTTP 301)، من المناسب أن يتم التحقّق من عنوان URL الذي تمت إعادة توجيهه مقابل ميزة "التصفّح الآمن من Google". إنّ التلاعب بعناوين URL من جهة العميل، مثل History.pushState، لا يؤدي إلى التحقّق من عناوين URL الجديدة مقارنةً بميزة "التصفّح الآمن من 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
  • التطبيقات التي قد تتسبّب بضرر (لنظام التشغيل Android فقط): https://developers.google.com/android/play-protect/potentially-harmful-applications
• عند عرض تحذيرات للصفحات التي حدّدتها "خدمة التصفّح الآمن" على أنّها خطيرة، عليك نَسب العمل إلى Google من خلال تضمين السطر "تنبيه من Google" مع رابط إلى تنبيه التصفُّح الآمن. إذا كان منتجك يعرض أيضًا تحذيرات استنادًا إلى مصادر أخرى، يجب عدم تضمين إحالة Google في التحذيرات المستمَدّة من بيانات غير تابعة لشركة Google.

• يجب تقديم إشعار في مستندات المنتج لإعلام المستخدمين بأنّ الحماية التي توفّرها ميزة "التصفّح الآمن من Google" ليست مثالية. ويجب أن تُعلمهم بأنّ هناك فرصة في حال ظهور نتائج موجبة خاطئة (أي المواقع الإلكترونية الآمنة التي يتم وضع علامة عليها على أنّها خطيرة) ونتائج سالبة خاطئة (أي المواقع الإلكترونية الخطيرة التي لم يتم وضع علامة عليها). نقترح استخدام اللغة التالية:

  تعمل Google على توفير أحدث المعلومات وأكثرها دقة حول مصادر الويب غير الآمنة. ومع ذلك، لا يمكن أن تضمن Google أن تكون معلوماتها شاملة وخالية من الأخطاء: فقد لا يتم تحديد بعض المواقع الخطيرة، وقد يتم تحديد بعض المواقع الآمنة عن طريق الخطأ.

أوضاع العمل

يتيح الإصدار 5 من التصفح الآمن من Google للعملاء الاختيار من بين ثلاثة أوضاع عمل.

وضع الوقت الفعلي

عندما يختار العملاء استخدام الإصدار 5 من ميزة "التصفّح الآمن من Google" في وضع الوقت الفعلي، سيحتفظون في قاعدة البيانات المحلية بما يلي: (1) ذاكرة تخزين مؤقت عمومية للمواقع الإلكترونية المحتمَلة، تكون بتنسيق كتجزئات SHA256 من تعبيرات عناوين URL التي تخضع للاحقة المضيف/المسار، (2) مجموعة من قوائم التهديدات المنسَّقة كبادئات تجزئة لعناوين URL للاحقة المضيف أو المسار. والفكرة عالية المستوى هي أنه عندما يريد العميل التحقق من عنوان URL معين، يتم إجراء فحص محلي باستخدام ذاكرة التخزين المؤقت العالمية. وفي حال اجتياز عملية الفحص هذه، يتم إجراء عملية تحقّق من قوائم التهديدات المحلية. وبخلاف ذلك، يواصل العميل إجراء عملية التحقّق من التجزئة في الوقت الفعلي كما هو موضّح أدناه.

وبالإضافة إلى قاعدة البيانات المحلية، سيحتفظ العميل بذاكرة تخزين مؤقت محلية. لا يلزم وجود مثل هذه ذاكرة التخزين المؤقت المحلية في سعة التخزين الدائمة وقد يتم محوها في حالة ضغط الذاكرة.

تتوفر أدناه المواصفات التفصيلية للإجراءات.

وضع القائمة المحلية

عندما يختار العملاء استخدام الإصدار 5 من "التصفّح الآمن من Google" في هذا الوضع، يكون سلوك العميل مشابهًا للإصدار 4 Update API من واجهة برمجة التطبيقات باستثناء استخدام الإصدار 5 من واجهة برمجة التطبيقات المحسّنة. وسيحتفظ العملاء في قاعدة البيانات المحلية بمجموعة من قوائم التهديدات المنسّقة كبادئات تجزئة متوافقة مع SHA256 لتعبيرات عنوان URL الذي يتبع المضيف/المسار. وعندما يريد العميل التحقّق من عنوان URL معيّن، يتم إجراء عملية تحقّق باستخدام قائمة التهديدات المحلية. وفي حالة وجود تطابق فقط، يتصل العميل بالخادم لمتابعة عملية التحقق.

وكما هو الحال أعلاه، سيحتفظ العميل أيضًا بذاكرة تخزين مؤقت محلية لا يلزم أن تكون في وحدة تخزين دائمة.

وضع "بدون مساحة تخزين" في الوقت الفعلي

عندما يختار العملاء استخدام الإصدار 5 من "التصفّح الآمن من Google" في وضع عدم توفّر مساحة تخزين في الوقت الفعلي، لا يحتاج العميل إلى الاحتفاظ بأي قاعدة بيانات محلية دائمة. ومع ذلك، لا يزال من المتوقع أن يحتفظ العميل بذاكرة تخزين مؤقت محلية. لا يلزم وجود مثل هذه ذاكرة التخزين المؤقت المحلية في سعة التخزين الدائمة وقد يتم محوها في حالة ضغط الذاكرة.

وعندما يرغب العميل في التحقق من عنوان URL معين، يتصل العميل دائمًا بالخادم لإجراء فحص. وهذا الوضع يشبه ما قد ينفذه عملاء الإصدار 4 من واجهة برمجة التطبيقات للبحث.

ومقارنةً بوضع الوقت الفعلي، قد يستخدم هذا الوضع معدل نقل بيانات أكبر للشبكة، ولكن قد يكون أكثر ملاءمةً إذا كان من غير الملائم للعميل الحفاظ على الحالة المحلية المستمرة.

التحقق من عناوين URL

يحتوي هذا القسم على مواصفات تفصيلية حول كيفية تحقّق العملاء من عناوين URL.

تحديد عنوان URL الأساسي

قبل التحقّق من أي عناوين URL، من المتوقّع أن يُجري العميل عملية تحديد عنوان URL الأساسي على هذا العنوان.

في البداية، نفترض أنّ العميل قد حلّل عنوان URL وجعله صالحًا وفقًا لمعيار RFC 2396. إذا كان عنوان URL يستخدم اسم نطاق دولي (IDN)، على العميل تحويل عنوان URL إلى تمثيل ASCII Punycode. يجب أن يشتمل عنوان URL على مكون مسار، أي أنّه يجب أن يحتوي على شرطة مائلة واحدة على الأقل تتبع النطاق (http://google.com/ بدلاً من http://google.com).

أولاً، أزِل أحرف علامات التبويب (0x09) وCR (0x0d) وLF (0x0a) من عنوان URL. ويجب عدم إزالة تسلسلات الهروب لهذه الأحرف (مثل %0a).

ثانيًا، إذا كان عنوان URL ينتهي بجزء، أزِل ذلك الجزء. على سبيل المثال، اختصِر الاسم من http://google.com/#frag إلى http://google.com/.

ثالثًا، يتم تجنّب إلغاء عنوان URL بشكل متكرر مع عدم وجود المزيد من حروف إلغاء النسبة المئوية. (قد يؤدي ذلك إلى عرض عنوان URL غير صالح).

لتحديد عنوان URL الأساسي لاسم المضيف:

استخرِج اسم المضيف من عنوان URL، ثمّ:

1. إزالة جميع النقاط البادئة واللاحقة.
2. استبدِل النقاط المتتالية بنقطة واحدة.
3. إذا كان من الممكن تحليل اسم المضيف على أنه عنوان IPv4، عليك تسويته إلى 4 قيم عشرية مفصولة بالنقاط. يجب أن يتعامل العميل مع أي ترميز قانوني لعنوان IP، بما في ذلك الترميز الثماني والسداسي عشري وأقل من أربعة مكونات.
4. إذا كان من الممكن تحليل اسم المضيف باعتباره عنوان IPv6 بين قوسين، عليك تسويته بإزالة الأصفار البادئة غير الضرورية في المكونات وتصغير أي مكوّنات باستخدام البنية المنقوطة المزدوجة. على سبيل المثال، يجب تحويل [2001:0db8:0000::1] إلى [2001:db8::1]. إذا كان اسم المضيف هو أحد نوعَي عناوين IPv6 الخاصة التالية، يمكنك تحويلهما إلى IPv4:
   • عنوان IPv6 تم ربطه ببروتوكول IPv4، مثل [::ffff:1.2.3.4]، والذي يجب تحويله إلى 1.2.3.4
   • عنوان NAT64 يستخدم البادئة المعروفة 64:ff9b::/96، مثل [64:ff9b::1.2.3.4]، والذي يجب تحويله إلى 1.2.3.4.
5. اجعل السلسلة بأكملها صغيرة.

لتحديد عنوان URL الأساسي للمسار:

1. حلُّ التسلسلات /../ و/./ في المسار عن طريق استبدال /./ بـ /، وإزالة /../ مع مكوِّن المسار السابق
2. يمكنك استبدال عمليات الشرطة المائلة المتتالية بحرف شرطة مائلة واحدة.

لا تطبِّق عمليات تحديد عنوان URL الأساسي هذه للمسار على مَعلمات طلب البحث.

في عنوان URL، استخدِم النسبة المئوية لإلغاء جميع الأحرف بالشكل== ASCII 32 أو >= 127 أو # أو %. يجب أن تستخدم عمليات الإلغاء أحرفًا سداسية عشرية كبيرة.

تعبيرات بادئة المسار للاحقة المضيف

بعد تحديد عنوان URL الأساسي، تكون الخطوة التالية هي إنشاء تعبيرات اللاحقة/البادئة. ويتكون كل تعبير لاحقة/بادئة من لاحقة مضيف (أو مضيف كامل) وبادئة مسار (أو مسار كامل).

سينشئ العميل ما يصل إلى 30 تركيبة مختلفة من لاحقة المضيف وبادئة المسار. تستخدم هذه المجموعات مكونات المضيف والمسار لعنوان URL فقط. يتم تجاهل المخطط واسم المستخدم وكلمة المرور والمنفذ. إذا كان عنوان URL يتضمّن مَعلمات طلب بحث، ستتضمّن مجموعة واحدة على الأقل المسار الكامل ومَعلمات طلب البحث.

بالنسبة إلى المضيف، سيحاول العميل خمس سلاسل مختلفة كحدّ أقصى. وهي:

• إذا لم يكن اسم المضيف رقم IPv4 أو IPv6 حرفيًا، يتم تكوين ما يصل إلى أربعة أسماء مضيفين من خلال البدء بنطاق eTLD+1 وإضافة مكونات بادئة متتالية. يجب أن يستند تحديد نطاق eTLD+1 إلى قائمة اللواحق العامة. على سبيل المثال، قد ينتج عن a.b.example.com نطاق eTLD+1 الخاص بـ example.com بالإضافة إلى المضيف مع مكوّن مضيف إضافي واحد b.example.com.
• اسم المضيف الدقيق في عنوان URL. وفقًا للمثال السابق، سيتم التحقّق من السمة a.b.example.com.

بالنسبة إلى المسار، سيحاول العميل ست سلاسل مختلفة كحدّ أقصى. وهي:

• المسار الدقيق لعنوان URL، بما في ذلك مَعلمات طلب البحث.
• المسار الدقيق لعنوان URL، بدون مَعلمات طلب البحث.
• المسارات الأربعة التي تم تكوينها بالبدء من الجذر (/) وإلحاق مكونات المسار بالتتابع، بما في ذلك الشرطة المائلة اللاحقة.

توضّح الأمثلة التالية سلوك عملية التحقّق:

بالنسبة إلى عنوان URL http://a.b.com/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://a.b.c.d.e.f.com/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/

(ملاحظة: يُرجى تخطّي b.c.d.e.f.com، لأنّنا لن نأخذ سوى آخر خمسة مكوّنات لاسم المضيف واسم المضيف بالكامل.)

بالنسبة إلى عنوان 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/

التجزئة

تستخدم ميزة "التصفّح الآمن من Google" خوارزمية SHA256 حصريًا كوظيفة تجزئة. يجب تطبيق دالة التجزئة هذه على التعبيرات أعلاه.

وفقًا للظروف، يتم اقتطاع التجزئة الكاملة 32 بايت إلى 4 بايت أو 8 بايت أو 16 بايت:

• عند استخدام طريقةhashes.search، نطلب حاليًا قطع قيم التجزئة في الطلب إلى 4 بايت بالضبط. سيؤدي إرسال وحدات بايت إضافية في هذا الطلب إلى انتهاك خصوصية المستخدم.

• عند تنزيل القوائم لقاعدة البيانات المحلية باستخدام طريقةhashList.get أو hashLists.batchGet، يتأثر طول علامات التجزئة التي يرسلها الخادم بكل من طبيعة القائمة وتفضيل العميل لطول التجزئة، والذي يتم توصيله من خلال المعلمة desired_hash_length.

إجراء فحص عنوان URL في الوقت الفعلي

يُستخدم هذا الإجراء عندما يختار العميل وضع التشغيل في الوقت الفعلي.

يتطلب هذا الإجراء عنوان URL واحدًا u ويعرض SAFE أو UNSAFE أو UNSURE. وفي حال عرض الرمز SAFE، يعتبر "التصفُّح الآمن من Google" عنوان URL آمنًا. وفي حال عرض رمز الاستجابة UNSAFE، قد تعتبر ميزة "التصفّح الآمن من Google" عنوان URL غير آمن، ويجب اتّخاذ الإجراء المناسب: مثل عرض تحذير للمستخدم النهائي أو نقل رسالة مستلَمة إلى مجلد الرسائل غير المرغوب فيها أو طلب تأكيد إضافي من المستخدم قبل المتابعة. في حال إرجاع UNSURE، يجب اتّباع إجراء الفحص المحلي التالي بعد ذلك.

1. يجب أن تكون السمة expressions قائمة بتعبيرات اللاحقة/البادئة التي يتم إنشاؤها بواسطة عنوان URL u.
2. يتم تحديد expressionHashes على شكل قائمة، حيث تكون العناصر عبارة عن تجزئات SHA256 لكل تعبير في expressions.
3. لكل hash من expressionHashes:
   1. إذا تم العثور على hash في ذاكرة التخزين المؤقت العمومية، يمكنك عرض UNSURE.
4. يجب ضبط السمة expressionHashPrefixes على شكل قائمة، بحيث تكون العناصر فيها أول 4 بايت من كل تجزئة في expressionHashes.
5. لكل expressionHashPrefix من expressionHashPrefixes:
   1. ابحث عن expressionHashPrefix في ذاكرة التخزين المؤقت على الجهاز.
   2. في حال العثور على الإدخال المخزَّن مؤقتًا:
      1. يمكنك تحديد ما إذا كان الوقت الحالي أكبر من وقت انتهاء صلاحيته.
      2. في حال كانت القيمة أكبر:
         1. أزِل الإدخال المُخزَّن مؤقتًا الذي تم العثور عليه من ذاكرة التخزين المؤقت على الجهاز.
         2. تابع باستخدام التكرار الحلقي.
      3. إذا لم يكن أكبر:
         1. إزالة expressionHashPrefix بالتحديد من expressionHashPrefixes
         2. تحقَّق مما إذا كان قد تم العثور على التجزئة الكاملة المقابلة ضمن expressionHashes في الإدخال المخزَّنة مؤقتًا.
         3. وفي حال العثور عليه، يمكنك إرجاع UNSAFE.
         4. إذا لم يتم العثور عليه، فتابع باستخدام التكرار الحلقي.
   3. إذا لم يتم العثور على الإدخال المخزَّن مؤقتًا، يمكنك متابعة تنفيذ التكرار الحلقي.
6. أرسِل expressionHashPrefixes إلى خادم الإصدار 5 من ميزة "التصفّح الآمن من Google" باستخدام تجزئة SearchHashes لاستدعاء إجراء عن بُعد (RPC) أو طريقة REST hashes.search. إذا حدث خطأ (بما في ذلك أخطاء الشبكة أو أخطاء HTTP وما إلى ذلك)، اعرض UNSURE. في الحالات الأخرى، يجب أن تكون الاستجابة response المستلَمة من خادم SB، وهي قائمة تتضمّن علامات التجزئة الكاملة مع بعض المعلومات الإضافية التي تحدّد طبيعة التهديد (الهندسة الاجتماعية أو البرامج الضارة أو غير ذلك)، بالإضافة إلى وقت انتهاء صلاحية ذاكرة التخزين المؤقت expiration.
7. لكل fullHash من response:
   1. إدراج fullHash في ذاكرة التخزين المؤقت على الجهاز مع expiration
8. لكل fullHash من response:
   1. لن تكون isFound هي نتيجة البحث عن fullHash في expressionHashes.
   2. إذا تم ضبط السياسة isFound على "خطأ"، يمكنك مواصلة تنفيذ حلقة التكرار.
   3. إذا كانت isFound صحيحة، اعرض UNSAFE.
9. إرجاع SAFE

على الرغم من أن هذا البروتوكول يحدد متى يرسل العميل expressionHashPrefixes إلى الخادم، إلا أن هذا البروتوكول لا يحدد عمدًا كيفية إرسالها. على سبيل المثال، من المقبول أن يرسل العميل كل expressionHashPrefixes في طلب واحد، كما أنه من المقبول أيضًا أن يرسل العميل كل بادئة فردية في expressionHashPrefixes إلى الخادم في طلبات منفصلة (ربما تتم المتابعة بالتوازي). من المقبول أيضًا أن يرسل العميل بادئات تجزئة غير مرتبطة أو تم إنشاؤها عشوائيًا مع بادئات التجزئة في expressionHashPrefixes، طالما أنّ عدد بادئات التجزئة المرسَلة في الطلب الواحد لا يتجاوز 30.

إجراء التحقق من عناوين URL لقائمة LocalThreat

يُستخدم هذا الإجراء عندما يختار العميل وضع القائمة المحلية للعمل. ويتم استخدامها أيضًا عندما يعرض العميل إجراء RealTimeCheck أعلاه قيمة UNSURE.

يتطلّب هذا الإجراء عنوان URL واحدًا u ويعرض القيمة SAFE أو UNSAFE.

1. يجب أن تكون السمة expressions قائمة بتعبيرات اللاحقة/البادئة التي يتم إنشاؤها بواسطة عنوان URL u.
2. يتم تحديد expressionHashes على شكل قائمة، حيث تكون العناصر عبارة عن تجزئات SHA256 لكل تعبير في expressions.
3. يجب ضبط السمة expressionHashPrefixes على شكل قائمة، بحيث تكون العناصر فيها أول 4 بايت من كل تجزئة في expressionHashes.
4. لكل expressionHashPrefix من expressionHashPrefixes:
   1. ابحث عن expressionHashPrefix في ذاكرة التخزين المؤقت على الجهاز.
   2. في حال العثور على الإدخال المخزَّن مؤقتًا:
      1. يمكنك تحديد ما إذا كان الوقت الحالي أكبر من وقت انتهاء صلاحيته.
      2. في حال كانت القيمة أكبر:
         1. أزِل الإدخال المُخزَّن مؤقتًا الذي تم العثور عليه من ذاكرة التخزين المؤقت على الجهاز.
         2. تابع باستخدام التكرار الحلقي.
      3. إذا لم يكن أكبر:
         1. إزالة expressionHashPrefix بالتحديد من expressionHashPrefixes
         2. تحقَّق مما إذا كان قد تم العثور على التجزئة الكاملة المقابلة ضمن expressionHashes في الإدخال المخزَّنة مؤقتًا.
         3. وفي حال العثور عليه، يمكنك إرجاع UNSAFE.
         4. إذا لم يتم العثور عليه، فتابع باستخدام التكرار الحلقي.
   3. إذا لم يتم العثور على الإدخال المخزَّن مؤقتًا، يمكنك متابعة تنفيذ التكرار الحلقي.
5. لكل expressionHashPrefix من expressionHashPrefixes:
   1. ابحث عن "expressionHashPrefix" في قاعدة بيانات قائمة التهديدات على الجهاز.
   2. إذا تعذّر العثور على expressionHashPrefix في قاعدة بيانات قائمة التهديدات المحلية، عليك إزالتها من expressionHashPrefixes.
6. أرسِل expressionHashPrefixes إلى خادم الإصدار 5 من ميزة "التصفّح الآمن من Google" باستخدام تجزئة SearchHashes لاستدعاء إجراء عن بُعد (RPC) أو طريقة REST hashes.search. إذا حدث خطأ (بما في ذلك أخطاء الشبكة أو أخطاء HTTP وما إلى ذلك)، اعرض SAFE. في الحالات الأخرى، يجب أن تكون الاستجابة response المستلَمة من خادم SB، وهي قائمة تتضمّن علامات التجزئة الكاملة مع بعض المعلومات الإضافية التي تحدّد طبيعة التهديد (الهندسة الاجتماعية أو البرامج الضارة أو غير ذلك)، بالإضافة إلى وقت انتهاء صلاحية ذاكرة التخزين المؤقت expiration.
7. لكل fullHash من response:
   1. إدراج fullHash في ذاكرة التخزين المؤقت على الجهاز مع expiration
8. لكل fullHash من response:
   1. لن تكون isFound هي نتيجة البحث عن fullHash في expressionHashes.
   2. إذا تم ضبط السياسة isFound على "خطأ"، يمكنك مواصلة تنفيذ حلقة التكرار.
   3. إذا كانت isFound صحيحة، اعرض UNSAFE.
9. إرجاع SAFE

إجراء فحص عنوان URL في الوقت الفعلي بدون قاعدة بيانات محلية

يتم استخدام هذا الإجراء عندما يختار العميل وضع التشغيل في الوقت الفعلي "بلا مساحة تخزين".

يتطلّب هذا الإجراء عنوان URL واحدًا u ويعرض القيمة SAFE أو UNSAFE.

1. يجب أن تكون السمة expressions قائمة بتعبيرات اللاحقة/البادئة التي يتم إنشاؤها بواسطة عنوان URL u.
2. يتم تحديد expressionHashes على شكل قائمة، حيث تكون العناصر عبارة عن تجزئات SHA256 لكل تعبير في expressions.
3. يجب ضبط السمة expressionHashPrefixes على شكل قائمة، بحيث تكون العناصر فيها أول 4 بايت من كل تجزئة في expressionHashes.
4. لكل expressionHashPrefix من expressionHashPrefixes:
   1. ابحث عن expressionHashPrefix في ذاكرة التخزين المؤقت على الجهاز.
   2. في حال العثور على الإدخال المخزَّن مؤقتًا:
      1. يمكنك تحديد ما إذا كان الوقت الحالي أكبر من وقت انتهاء صلاحيته.
      2. في حال كانت القيمة أكبر:
         1. أزِل الإدخال المُخزَّن مؤقتًا الذي تم العثور عليه من ذاكرة التخزين المؤقت على الجهاز.
         2. تابع باستخدام التكرار الحلقي.
      3. إذا لم يكن أكبر:
         1. إزالة expressionHashPrefix بالتحديد من expressionHashPrefixes
         2. تحقَّق مما إذا كان قد تم العثور على التجزئة الكاملة المقابلة ضمن expressionHashes في الإدخال المخزَّنة مؤقتًا.
         3. وفي حال العثور عليه، يمكنك إرجاع UNSAFE.
         4. إذا لم يتم العثور عليه، فتابع باستخدام التكرار الحلقي.
   3. إذا لم يتم العثور على الإدخال المخزَّن مؤقتًا، يمكنك متابعة تنفيذ التكرار الحلقي.
5. أرسِل expressionHashPrefixes إلى خادم الإصدار 5 من ميزة "التصفّح الآمن من Google" باستخدام تجزئة SearchHashes لاستدعاء إجراء عن بُعد (RPC) أو طريقة REST hashes.search. إذا حدث خطأ (بما في ذلك أخطاء الشبكة أو أخطاء HTTP وما إلى ذلك)، اعرض SAFE. في الحالات الأخرى، يجب أن تكون الاستجابة response المستلَمة من خادم SB، وهي قائمة تتضمّن علامات التجزئة الكاملة مع بعض المعلومات الإضافية التي تحدّد طبيعة التهديد (الهندسة الاجتماعية أو البرامج الضارة أو غير ذلك)، بالإضافة إلى وقت انتهاء صلاحية ذاكرة التخزين المؤقت expiration.
6. لكل fullHash من response:
   1. إدراج fullHash في ذاكرة التخزين المؤقت على الجهاز مع expiration
7. لكل fullHash من response:
   1. لن تكون isFound هي نتيجة البحث عن fullHash في expressionHashes.
   2. إذا تم ضبط السياسة isFound على "خطأ"، يمكنك مواصلة تنفيذ حلقة التكرار.
   3. إذا كانت isFound صحيحة، اعرض UNSAFE.
8. إرجاع SAFE

تمامًا مثل إجراء فحص عنوان URL في الوقت الفعلي، لا يحدد هذا الإجراء بالضبط كيفية إرسال بادئات التجزئة إلى الخادم. على سبيل المثال، من المقبول أن يرسل العميل كل expressionHashPrefixes في طلب واحد، كما أنه من المقبول أيضًا أن يرسل العميل كل بادئة فردية في expressionHashPrefixes إلى الخادم في طلبات منفصلة (ربما تتم المتابعة بالتوازي). من المقبول أيضًا أن يرسل العميل بادئات تجزئة غير مرتبطة أو تم إنشاؤها عشوائيًا مع بادئات التجزئة في expressionHashPrefixes، طالما أنّ عدد بادئات التجزئة المرسَلة في الطلب الواحد لا يتجاوز 30.

صيانة قاعدة البيانات المحلية

يتوقع الإصدار 5 من "التصفّح الآمن من Google" أن يحتفظ العميل بقاعدة بيانات محلية، إلا عندما يختار العميل وضع "الوقت الفعلي بلا مساحة تخزين". الأمر متروك للعميل لتنسيق قاعدة البيانات المحلية هذه وتخزينها. من الناحية النظرية، يمكن اعتبار محتوى قاعدة البيانات المحلية هذه مجلدًا يحتوي على قوائم مختلفة كملفات، ومحتوى هذه الملفات هو تجزئات SHA256 أو بادئات تجزئة.

تحديثات قاعدة البيانات

سيستدعي العميل بانتظام hashList.get أو hashLists.batchGet لتحديث قاعدة البيانات. وبما أنّ العميل النموذجي سيرغب في تعديل قوائم متعددة في وقت واحد، يُنصَح باستخدام طريقة hashLists.batchGet.

يتم تعريف القوائم بأسمائها المميزة. الأسماء هي سلاسل ASCII قصيرة تتكون من بضعة أحرف.

على عكس الإصدار 4، يتم تحديد القوائم حسب اسم نوع التهديد ونوع النظام الأساسي ونوع إدخال التهديد في قوائم الإصدار 5. ويوفِّر ذلك مرونة في حال تم رصد نوع التهديد نفسه من قوائم الإصدار 5 المتعددة. تمت إزالة أنواع الأنظمة الأساسية وأنواع إدخالات التهديدات في الإصدار 5.

بعد اختيار اسم للقائمة، لن تتم إعادة تسميته أبدًا. علاوةً على ذلك، بعد ظهور القائمة، لن تتم إزالتها أبدًا (إذا لم تعُد القائمة مفيدة، ستصبح فارغة ولكنها ستظل موجودة). لذا، من المناسب إدخال رموز برمجية ثابتة لهذه الأسماء في رمز عميل "التصفّح الآمن من Google".

تتيح كل من طريقةhashList.get وطريقةhashLists.batchGet استخدام التحديثات التزايدية. ويؤدي استخدام التحديثات التزايدية إلى توفير معدّل نقل البيانات وتحسين الأداء. تعمل التحديثات التزايدية من خلال تقديم دلتا بين إصدار القائمة وأحدث إصدار من القائمة. (في حال نشر العميل حديثًا ولا تتوفّر له أي إصدارات، يتوفّر تحديث كامل). يشتمل التحديث التزايدي على فهارس وإضافات إزالة. يُتوقع من العميل أولاً إزالة الإدخالات في الفهارس المحددة من قاعدة البيانات المحلية، ثم تطبيق الإضافات.

وأخيرًا، لمنع التلف، يجب على العميل التحقق من البيانات المخزنة مقابل المجموع الاختباري الذي يوفره الخادم. وعندما لا يتطابق المجموع الاختباري، يجب على العميل إجراء تحديث كامل.

فك ترميز محتوى القائمة

فك ترميز علامات التجزئة وبادئات التجزئة

يتم تقديم جميع القوائم باستخدام ترميز خاص لتصغير الحجم. يعمل هذا الترميز من خلال إدراك أنّ قوائم "التصفّح الآمن من Google" تحتوي، من الناحية النظرية، على مجموعة من علامات التجزئة أو بادئات التجزئة التي لا يمكن تمييزها إحصائيًا عن الأعداد الصحيحة العشوائية. إذا كنا نريد ترتيب هذه الأعداد الصحيحة وأخذ الفرق المجاور لها، فمن المتوقع أن يكون هذا الفرق المجاور "صغيرًا" إلى حد ما. وبالتالي، يستغل ترميز Golomb-Rice هذا الحجم الصغير.

لنفترض أنّه سيتم إرسال ثلاثة تعبيرات تبدأ ببادئة المسار للاحقة المضيف، وهي a.example.com/ وb.example.com/ وy.example.com/، باستخدام بادئات تجزئة بحجم 4 بايت. افترض أيضًا أنه تم اختيار معلمة Rice، التي يشار إليها بواسطة k، لتكون 30. سيبدأ الخادم بحساب التجزئة الكاملة لهذه السلاسل، وهي على التوالي:

291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc  a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c  b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03  y.example.com/

ينشئ الخادم بعد ذلك بادئات تجزئة 4 بايت لكل مما سبق، وهي أول 4 بايت من التجزئة الكاملة بحجم 32 بايت، ويتم تفسيرها على أنها أعداد صحيحة 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 بت بالضبط؛ بينما يتم ترميز الباقي مباشرةً باستخدام وحدات بت. يكون حاصل قسمة الرقم الأول بالترميز 0، بينما يكون الجزء المتبقي بالترميز 00101111101001000000000111010. أما قسم حاصل قسمة الرقم الثاني فهو 0111، والجزء الباقي 001110100110100101000000000101010.

عندما يتم تشكيل هذه الأرقام في سلسلة بايت، يتم استخدام endian الصغير. من الناحية النظرية، قد يكون من الأسهل تصوّر سلسلة بت طويلة يتم تكوينها من وحدات البت الأقل أهمية: نأخذ قسم القسمة من الرقم الأول ونضيف الجزء المتبقي من الرقم الأول ونضيف الجزء المتبقي من الرقم إلى حاصل قسمة الرقم الثاني ونضيف الجزء المتبقي قبله. سينتج عن ذلك العدد الكبير التالي (فواصل الأسطر والتعليقات التي تمت إضافتها للتوضيح):

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

يتضح من ذلك أننا نلاحظ من الناحية النظرية أنه نظرًا إلى أننا prepend إلى العدد الكبير على اليسار (أي إضافة وحدات بت ذات أهمية أكبر)، إلا أننا نعمل على الترميز من اليمين (أي وحدات البت الأقل أهمية)، يمكن تنفيذ الترميز وفك التشفير بشكل تدريجي.

يؤدي هذا أخيرًا إلى

additions_four_bytes {
  first_value: 489866504
  rice_parameter: 30
  entries_count: 2
  encoded_data: "t\000\322\227\033\355It\000"
}

يتبع العميل الخطوات أعلاه ببساطة لفك ترميز بادئات التجزئة. على عكس الإصدار 4، لا حاجة إلى تبديل البايت في النهاية لأنّ الأعداد الصحيحة لبادئة التجزئة يتم تفسيرها على أنّها أرقام نهاية كبيرة.

فك ترميز مؤشرات الإزالة

ويتم ترميز فهارس الإزالة باستخدام الأسلوب نفسه الوارد أعلاه باستخدام الأعداد الصحيحة 32 بت. لم يتغير ترميز فهارس الإزالة وفك ترميزها بين الإصدار 4 و5.

القوائم المتاحة

يوصى باستخدام القوائم التالية في v5alpha1:

اسم القائمة	الإصدار 4 المقابل من تعداد ThreatType	الوصف
gc	لا ينطبق	هذه القائمة هي قائمة ذاكرة تخزين مؤقت عمومية. وهي قائمة خاصة لا تُستخدم إلا في وضع التشغيل في الوقت الفعلي.
se	SOCIAL_ENGINEERING	تحتوي هذه القائمة على تهديدات من نوع التهديد SOCIAL_ENGINEERING.
mw	MALWARE	تحتوي هذه القائمة على تهديدات من نوع التهديد لبرامج ضارة على الأنظمة الأساسية لسطح المكتب.
uws	UNWANTED_SOFTWARE	تحتوي هذه القائمة على تهديدات من نوع التهديد UNWANTED_ستعرض الأنظمة الأساسية لسطح المكتب.
uwsa	UNWANTED_SOFTWARE	تحتوي هذه القائمة على تهديدات من نوع التهديد UNWANTED_ستعرض أنظمة Android الأساسية.
pha	POTENTIALLY_HARMFUL_APPLICATION	تحتوي هذه القائمة على تهديدات من نوع التهديد POTENTIALLY_HARMFUL_APPLICATION على أنظمة Android الأساسية.

ستتوفر قوائم إضافية في تاريخ لاحق، وسيتم توسيع الجدول أعلاه في هذا الوقت.

يُسمح للعميل بتشغيل خادم وكيل للتخزين المؤقت لاسترداد بعض القوائم أعلاه أو جميعها، ثم جعل العميل يتصل بالخادم الوكيل. إذا تم تنفيذ ذلك، ننصح بأن تكون مدة ذاكرة التخزين المؤقت قصيرة مثل خمس دقائق. وفي المستقبل، يمكن تحديد مدة ذاكرة التخزين المؤقت هذه باستخدام عنوان HTTP العادي الذي يتضمّن Cache-Control.

معدل التحديثات

على العميل فحص القيمة التي يعرضها الخادم في الحقل minimum_wait_duration واستخدامها لجدولة عملية التحديث التالي لقاعدة البيانات. ومن المحتمل أن تكون هذه القيمة صفرًا (الحقل minimum_wait_duration مفقود تمامًا)، وفي هذه الحالة على العميل إجراء تعديل آخر على الفور.

أمثلة على الطلبات

يوثّق هذا القسم بعض الأمثلة على استخدام HTTP API مباشرةً للوصول إلى ميزة "التصفّح الآمن من Google". يُنصح عمومًا باستخدام ربط لغة تم إنشاؤه لأنّه سيعالج الترميز وفك الترميز تلقائيًا بطريقة ملائمة. يُرجى الاطّلاع على المستندات الخاصة بعملية الربط هذه.

في ما يلي مثال على طلب HTTP باستخدام طريقةhashes.search:

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

نص الاستجابة هو حمولة بيانات منسقة للبروتوكول المخزن المؤقت والتي يمكنك بعد ذلك فك ترميزها.

في ما يلي مثال على طلب HTTP باستخدام طريقة hashLists.batchGet:

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

ويكون نص الاستجابة، مرة أخرى، حمولة بتنسيق مخزن مؤقت للبروتوكول يمكنك فك ترميزه بعد ذلك.

دليل نقل البيانات

إذا كنت تستخدم حاليًا v4 Update API، يتوفّر مسار نقل سلس من الإصدار 4 إلى الإصدار 5 بدون الحاجة إلى إعادة ضبط قاعدة البيانات المحلية أو محوها. يوثّق هذا القسم كيفية القيام بذلك.

جارٍ تحويل تعديلات القائمة

وفي الإصدار 4، قد يستخدم المرء طريقة threatListUpdates.fetch لتنزيل القوائم. وفي الإصدار 5، يتم التبديل إلى طريقةhashLists.batchGet.

يجب إجراء التغييرات التالية على الطلب:

1. أزِل كائن الإصدار 4 من ClientInfo تمامًا. بدلاً من تقديم تعريف العميل باستخدام حقل مخصّص، ما عليك سوى استخدام عنوان وكيل المستخدم المعروف. ورغم عدم وجود تنسيق محدد لتوفير تعريف العميل في هذا العنوان، نقترح تضمين معرّف العميل الأصلي وإصدار العميل فقط مع الفصل بينهما بمسافة أو حرف شرطة مائلة.
2. لكل عنصر من كائنات الإصدار 4 من ListUpdateRequest:
   • ابحث عن اسم قائمة الإصدار 5 المقابل في الجدول أعلاه وأدخِل هذا الاسم في طلب الإصدار 5.
   • أزِل الحقول غير اللازمة، مثل threat_entry_type أو platform_type.
   • يتوافق الحقل state في الإصدار 4 مباشرةً مع حقل الإصدار 5 versions. يمكن إرسال سلسلة البايت نفسها التي سيتم إرسالها إلى الخادم باستخدام الحقل state في الإصدار 4 في الإصدار 5 باستخدام الحقل versions.
   • بالنسبة إلى قيود الإصدار 4، يستخدم الإصدار 5 إصدارًا مبسطًا يُسمى SizeConstraints. يجب تجاهل الحقول الإضافية مثل region.

يجب إجراء التغييرات التالية على الرد:

1. يتم ببساطة استبدال التعداد ResponseType بالإصدار 4 بحقل منطقي يُسمّى partial_update.
2. ويمكن أن يكون الحقل minimum_wait_duration صفرًا الآن أو مُحذَفًا. وفي هذه الحالة، يُطلَب من العميل تقديم طلب آخر فورًا. لا يحدث ذلك إلا عندما يحدِّد العميل في SizeConstraints قيدًا أصغر على الحدّ الأقصى لحجم التحديث من الحدّ الأقصى لحجم قاعدة البيانات.
3. سيلزم تعديل خوارزمية فك ترميز Rice للأعداد الصحيحة 32 بت. ويتمثّل الاختلاف بين البيانات في أنّ البيانات المرمّزة بترميز مختلف. في الإصدارَين 4 و5، يتم ترتيب بادئات التجزئة 32 بت بطريقة قاموسًا. في الإصدار 4، يتم التعامل مع هذه البادئات على أنّها نهاية صغيرة عند ترتيبها، بينما يتم التعامل مع هذه البادئات في الإصدار 5 على أنّها نهاية كبيرة عند ترتيبها. هذا يعني أن العميل لا يحتاج إلى القيام بأي فرز، لأن الفرز المعجم يتطابق مع الفرز الرقمي ذو النهاية الكبيرة. يمكنك الاطّلاع هنا على مثال من هذا النوع في عملية تنفيذ الإصدار 4 من Chromium. يمكنك إزالة هذا الترتيب.
4. يجب تنفيذ خوارزمية فك ترميز Rice لأطوال تجزئة أخرى.

تحويل عمليات بحث التجزئة

في الإصدار 4، قد يستخدم المرء طريقةfullHashes.find للحصول على تجزئات كاملة. الطريقة المكافئة في الإصدار 5 هي طريقةhases.search.

يجب إجراء التغييرات التالية على الطلب:

1. تنظيم الرمز البرمجي بحيث لا ترسل سوى بادئات تجزئة يبلغ طولها 4 بايت بالضبط.
2. إزالة كائنات الإصدار 4 من ClientInfo تمامًا. بدلاً من تقديم تعريف العميل باستخدام حقل مخصّص، ما عليك سوى استخدام عنوان وكيل المستخدم المعروف. ورغم عدم وجود تنسيق محدد لتوفير تعريف العميل في هذا العنوان، نقترح تضمين معرّف العميل الأصلي وإصدار العميل فقط مع الفصل بينهما بمسافة أو حرف شرطة مائلة.
3. أزِل الحقل client_states. لم يعد من الضروري استخدامه.
4. ولم تعُد هناك حاجة إلى تضمين threat_types وحقول مشابهة.

يجب إجراء التغييرات التالية على الرد:

1. تمت إزالة الحقل minimum_wait_duration. يمكن للعميل دائمًا إصدار طلب جديد حسب الحاجة.
2. تم تبسيط الكائن ThreatMatch الإصدار 4 في الكائن FullHash.
3. تم تبسيط التخزين المؤقت في مدة ذاكرة تخزين مؤقت واحدة. يمكنك الاطّلاع على الإجراءات الواردة أعلاه بشأن التفاعل مع ذاكرة التخزين المؤقت.