Overview

مقدمة

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

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

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

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

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

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

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

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

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

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

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

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

السعر

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

الحصص

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

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

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

إذا أدت زيارة عنوان URL إلى إعادة توجيه (مثل HTTP 301)، من المناسب فحص عنوان URL الذي تمت إعادة توجيهه مقابل ميزة "التصفّح الآمن من Google". لا يؤدي التلاعب بعناوين URL من جهة العميل، مثل History.pushState، إلى فحص عناوين URL الجديدة باستخدام ميزة "التصفُّح الآمن من Google".

تحذيرات المستخدم

إذا كنت تستخدم ميزة "التصفُّح الآمن من Google" لتحذير المستخدمين من المخاطر من صفحات ويب معيَّنة، تسري الإرشادات التالية:

تساعد هذه الإرشادات في حمايتك أنت وGoogle من سوء الفهم من خلال توضيح أنّ الصفحة غير معروفة بنسبة 100% بأنّها مورد ويب غير آمن، وأنّ التحذيرات تكتفي بتحديد المخاطر المحتملة.

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

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

أوضاع العمل

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

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

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

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

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

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

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

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

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

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

جارٍ التحقق من عناوين URL

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

تحديد عنوان 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 عنوان URL، يُحتمل أن يكون غير آمن من خلال ميزة "التصفُّح الآمن من Google"، ويجب اتخاذ الإجراء المناسب، مثل عرض تحذير للمستخدم أو نقل رسالة مستلَمة إلى مجلد الرسائل غير المرغوب فيها أو طلب تأكيد إضافي من المستخدم قبل المتابعة. وإذا رجعت القيمة 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" باستخدام RPC SearchHashes أو طريقة 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 True، يجب عرض UNSAFE.
  9. تاريخ العودة: SAFE

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

يتم استخدام هذا الإجراء عندما يختار العميل وضع عمل القائمة المحلية. ويتم استخدامها أيضًا عندما يعرض العميل الإجراء 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" باستخدام RPC SearchHashes أو طريقة 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 True، يجب عرض 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" باستخدام RPC SearchHashes أو طريقة 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 True، يجب عرض UNSAFE.
  8. تاريخ العودة: SAFE

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

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

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

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

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

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

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

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

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

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

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

يحتوي الإصدار 5 من التصفح الآمن من Google على أربعة أنواع مختلفة لمعالجة بيانات 4 بايت وبيانات 8 بايت وبيانات 16 بايت وبيانات 32 بايت. لنلقِ نظرة على مثال يتم فيه تشفير ثلاثة أعداد صحيحة مكونة من 4 بايت متتالية رقميًا. لنفترض أن معلمة الأرز التي يرمز لها بالرمز k تكون 3. جزء ناتج الترميز هو ببساطة قيمة الفرق المتجاورة التي يتم إزاحتها لليمين بمقدار كيلو بت. بما أن الأعداد الصحيحة المحدّدة تكون متتابعة، يكون الفرق المتجاوِز هو 1، وبعد التغير بمقدار 3 بت، يكون جزء ناتج القسمة صفرًا. أقل وحدات بت بارزة هي 001. ويتم ترميز حاصل القسمة الصفري على أنه 0 بت فردي. قيمة الباقي 1، وتم ترميزها كـ 100. ويتكرر ذلك مرة أخرى لتشكيل مصدر بت 01000100. ويتم ترميز بث البت الناتج باستخدام النهاية الصغيرة مثل 00100010. وبالتالي يتجاوب مع البيانات التالية:

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

بعد خطوة فك الترميز أعلاه للأعداد الصحيحة المكونة من 32 بت، يمكن استخدام النتيجة مباشرةً كمؤشرات إزالة أو إضافات. على عكس الإصدار 4، ليست هناك حاجة لإجراء تبديل البايت بعد ذلك.

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

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

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

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

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

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

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

يوثّق هذا القسم بعض الأمثلة على استخدام واجهة برمجة تطبيقات HTTP مباشرةً للوصول إلى ميزة "التصفّح الآمن من 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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