Overview

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

يُعدّ حداثة البيانات وتغطية البيانات أحد التحسينات المهمة في الإصدار 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 مدخل HTTP المتوافق. هذه واجهة برمجة تطبيقات مصاحبة اختيارية. وعند استخدامه بالتزامن مع "التصفّح الآمن من Google"، يمكن للمستخدمين النهائيين لم يعد يتم إرسال عناوين IP إلى Google.

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

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

الأسعار

تتوفر جميع واجهات برمجة التطبيقات للتصفح الآمن من 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" في وضع الوقت الفعلي، سيحتفظون في قاعدة البيانات المحلية بما يلي: (1) ذاكرة تخزين مؤقت عمومية للمواقع الإلكترونية المحتملة الحميدة، يتمّ تنسيقها على شكل تجزئات SHA256 لتعبيرات عناوين URL للاحقة المضيف/المسار، (2) مجموعة من قوائم التهديدات المنسَّقة كبادئات تجزئة لبادئة SHA256 لتعبيرات عنوان URL للاحقة المضيف أو المسار. والفكرة عالية المستوى هي أنه عندما يريد العميل التحقق من عنوان URL معين، يتم إجراء فحص محلي باستخدام ذاكرة التخزين المؤقت العالمية. وفي حال اجتياز عملية الفحص هذه، يتم إجراء عملية تحقّق من قوائم التهديدات المحلية. بخلاف ذلك، يواصل العميل إجراء عملية التحقّق من التجزئة في الوقت الفعلي على النحو المفصّل أدناه.

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

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

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

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

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

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

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

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

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

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

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

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

أولاً، أزِل أحرف Tab (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.

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

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

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

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

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

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

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

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

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

001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part

00111010001001001111011010001101110010111110100100000000001110100

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

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

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

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

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

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

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

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

في الإصدار 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. تم تبسيط التخزين المؤقت في مدة ذاكرة تخزين مؤقت واحدة. يمكنك الاطّلاع على الإجراءات الواردة أعلاه بشأن التفاعل مع ذاكرة التخزين المؤقت.