الانتقال إلى المحتوى الرئيسي

نظرة عامة

تُشير التحذيرات في تقرير كشف الحيوية إلى كل حالة رصدتها Didit أثناء تشغيل فحص الحيوية. تظهر هذه التحذيرات في مصفوفة warnings[] الخاصة بكل عنصر داخل liveness_checks[] (راجع تقرير كشف الحيوية)، مع تعيين قيمة feature إلى "LIVENESS". يتبع كل إدخال هيكل كائن التحذير المشترك: feature وrisk وadditional_data وlog_type وshort_description وlong_description وnode_id. يتكون كل تحذير من ثلاث طبقات:
  1. رمز risk — معرّف ثابت يمكنك مطابقته برمجياً في الكود الخاص بك (الرموز الموضحة أدناه).
  2. نوع السجل log_type — إما information أو warning أو error. تحمل مخاطر الرفض التلقائي دائماً القيمة error. أما بالنسبة للمخاطر القابلة للتكوين، فتُشتق القيمة من الإجراء المضبوط: لا يوجد إجراء ← information، المراجعة ← warning، رفض ← error. وبالنسبة للمخاطر المرتبطة بالحدود (LOW_LIVENESS_SCORE وLOW_FACE_QUALITY)، تكون القيمة error عندما تنخفض القيمة إلى حد الرفض أو دونه، وتكون warning عندما تنخفض إلى حد المراجعة أو دونه فقط.
  3. التأثير على القرار — يوجّه منطق التوجيه نفسه حالة تقرير كشف الحيوية status: ينقله إجراء المراجعة إلى In Review (قيد المراجعة)، وينقله إجراء الرفض (أو أي خطر رفض تلقائي) إلى Declined (مرفوضة)، بينما يتركه خيار “لا يوجد إجراء” دون تغيير.
تُصدَر بعض المخاطر فقط عندما تكون طريقة كشف الحيوية هي PASSIVE (فحوصات الوجوه المتعددة والجودة والإضاءة). توضح الجداول أدناه المجموعة الكاملة لرموز مخاطر كشف الحيوية ومستويات خطورتها — ولا توجد أي رموز مخاطر أخرى لكشف الحيوية.

شروط الرفض التلقائي

تؤدي المخاطر التالية دائماً إلى فرض حالة Declined على تقرير كشف الحيوية (وكذلك على الجلسة)، مع log_type: "error": عند إطلاق NO_FACE_DETECTED، يتم حجب LOW_LIVENESS_SCORE (لعدم وجود وجه لاحتساب درجته).

إعدادات التحقق القابلة للتكوين

في لوحة تحكم Didit، يتم تجميع مخاطر كشف الحيوية تحت إعدادات سير العمل التالية:

التحذيرات الناتجة

كشف الحيوية الأساسي

سلامة قناة الالتقاط

إشارات هجوم الحقن التي يُبلغ عنها العميل وقت الالتقاط. على عكس هجمات العرض (عرض عنصر مصطنع أمام كاميرا حقيقية)، تصف هذه الإشارات استبدال بث الكاميرا نفسه أو اعتراضه. كل منها قابل للتكوين لكل سير عمل ويكون افتراضياً بلا إجراء، لذا فإن تفعيل الميزة لا يغير أي قرارات حتى تختار ذلك.
لا توفر المتصفحات أي إقرار لمصدر الكاميرا على مستوى نظام التشغيل لأي مزوّد، لذا فإن هذه الإشارات على الويب تُعد أدلة مؤيدة وليست إثباتاً قاطعاً. على الويب، تعني النتيجة null غير محددة (تسميات الأجهزة غير متوفرة حتى يتم منح إذن الكاميرا) ولا تُطلق خطراً أبداً.
يتم التعرف على الكاميرا الافتراضية من خلال اسم جهازها، لذلك لا يتم التعرف على الكاميرا التي يعرضها نظام التشغيل تحت اسم عادي بهذه الطريقة. داخل محاكي Android، تتم تسمية الكاميرا المعاد تعيينها مثل أي كاميرا مدمجة، ولهذا السبب يتم الإبلاغ عن حالة الأجهزة المحاكاة عبر FRAME_INJECTION_SUSPECTED بدلاً من ذلك: حيث يتم اكتشافها من بيئة الجهاز - مكدس العرض وطراز الجهاز المُبلغ عنه في وكيل المستخدم - بدلاً من اسم الكاميرا. تحمل النتائج الصادرة من بيئة الجهاز additional_data.reason: "emulated_capture_device"، مما يميزها عن تحليل الإطارات الخاص بنموذج كشف الحيوية نفسه.
إن اكتشاف الجهاز من المتصفح هو دليل وليس إقراراً، ويمكن لمهاجم متمرس التدخل فيه. تُبلغ حزم SDK الأصلية للهاتف المحمول عن إشارات سلامة أقوى على مستوى نظام التشغيل لا يمكن للمتصفح رؤيتها (المحاكي، أو الأجهزة التي تتمتع بصلاحيات الجذر أو الأجهزة مكسورة الحماية، أو الربط وقت التشغيل، أو أداة تصحيح أخطاء متصلة)، ولكل منها إجراء خاص بها قابل للتكوين ضمن سلامة الجهاز وبيئة التشغيل. ترفع هذه الإشارات تكلفة المهاجم بشكل كبير، ولكنها بمفردها لا تثبت أن الالتقاط جاء من جهاز حقيقي. إشارات سلامة الجهاز مستقلة عن طريقة كشف الحيوية، لذا يمكن دمجها مع أي من التقنيات: Passive أو 3D Flash أو 3D Action & Flash.

التحليل الجنائي لسلامة التسجيل

يتم احتساب LIVENESS_VIDEO_ANOMALY على جانب الخادم على تسجيل كشف الحيوية المخزن، بشكل مستقل عن نموذج كشف الحيوية. ويكتشف تسلسلاً متحركاً يتكرر عبر دورات متعددة، بما يتوافق مع بث متكرر. حدد الإجراء في عقدة كشف الحيوية أو تقدير العمر الخاصة بك: يسجل NO_ACTION نتيجة معلوماتية، ويمكن لـ REVIEW تصعيد عملية تحقق تم البت فيها إلى قيد المراجعة، ويمكن لـ DECLINE تصعيدها إلى مرفوضة. يعمل الفحص بشكل غير متزامن، لذا قد يصل التصعيد بعد النتيجة الأولية. لا يتم خفض رتبة أي قرار حالي أكثر صرامة، ويتم الحفاظ على قرارات المراجعة اليدوية. تتضمن نتائج الإصدار 2 forensics_version: 2، وأدلة repeated_sequence وrepeated_moving_sequence في anomaly_reasons. تظل قياسات التسليم مثل unique_frame_ratio وstatic_pair_ratio وdecoded_fps_ratio وmax_frame_gap_seconds تشخيصية؛ ولا يمكنها إثبات إعادة التشغيل بمفردها. تصف النتائج الأقدم إصدار أداة الكشف المستخدمة في ذلك الوقت ولا يُعاد تصنيفها بأثر رجعي.
هذه إشارة إضافية متحفظة، وليست كشفاً شاملاً للوسائط الاصطناعية أو الفيديو المحقون. التسجيل الخالي من الحالات الشاذة ليس إثباتاً للحيوية. تظل عمليات الالتقاط القصيرة أو الغامضة وعمليات الالتقاط الخالية من أدلة إعادة تشغيل قابلة للاستخدام دون وضع علامة عليها بواسطة هذا الفحص. لا ينتج عن التسجيلات المفقودة أو غير القابلة للقراءة أي نتيجة من هذا الفحص؛ وتظل فحوصات التحقق الأخرى سارية.

مطابقة الوجه عبر الجلسات

بالنسبة لحالات التطابق مع الوجوه المستوردة أو الوجوه المدرجة في القوائم (التي ليس لها جلسة)، تكون قيم *_session_id و*_session_number وapi_service في additional_data هي null. تُستثنى الوجوه العائدة لنفس المستخدم (نفس vendor_data، أو نفس مستخدم المورّد عند توفره) من بحث الفهرس بأكمله — سواء كشف التكرار أو فحص قائمة الحظر. تكون أولوية التطابق: التطابق التام مع قائمة الحظر → التطابق التام مع قائمة السماح → التطابق التام المكرر → التطابق المحتمل مع قائمة الحظر → التطابق المحتمل مع قائمة السماح → التطابق المحتمل المكرر — يظهر رمز واحد فقط من هذه الرموز الستة المتنافية في كل تقرير. لا يُعد DUPLICATED_FACE_NAME_MISMATCH جزءًا من مجموعة الأولوية تلك: فهو رمز إضافي يُصدر بالإضافة إلى DUPLICATED_FACE عند فشل التحقق من الهوية أيضًا، ولا يحل محله أبدًا. لا يحتوي additional_data.name_match_score إطلاقًا على الأسماء التي تتم مقارنتها — بل المعرّفات والدرجة فقط، حتى لا تصل أي معلومات تعريف شخصية إلى payload التحذير. قد يحصل الاسم المكتوب بنظام كتابة مختلف في كل مستند (على سبيل المثال العبرية في أحدهما واللاتينية في الآخر) على درجة أقل من الحد حتى لو كانت كلتا الجلستين تعودان لنفس الشخص. في تلك الحالة تحديدًا، لا يُصدر DUPLICATED_FACE_NAME_MISMATCH عندما يثبت مستندا الهوية للجلستين صحة بعضهما البعض في كل ما يلي:
  • يحمل كلا المستندين نفس دولة الإصدار.
  • يتطابق معرّف تطابقًا تامًا بين المستندين. يُعامل document_number وpersonal_number بالتبادل، لأن الرقم الوطني نفسه قد يوضع في أيٍّ من الحقلين وفقًا لنوع المستند.
  • إذا كان كلا المستندين يتضمنان تاريخ ميلاد، فيجب أن يكون التاريخ نفسه.
إذا كانت الأسماء مكتوبة بنفس نظام الكتابة، أو إذا اختلف المعرّف أو دولة الإصدار أو كان أحدهما مفقودًا، أو إذا تعارضت تواريخ الميلاد، فسيظل التحذير يُصدر كما هو موضح أعلاه.

جودة كشف الحيوية السلبي (فقط عندما يكون method = "PASSIVE")

LOW_FACE_LUMINANCE وHIGH_FACE_LUMINANCE متنافيان — فالسطوع إما أن يكون أقل من الحد الأدنى أو أعلى من الحد الأقصى، ولا يمكن أن يكون كلاهما معًا أبدًا.

تقدير العمر (مسارات سير العمل التكيفية وعُقد AGE_ESTIMATION)

نصوص الوصف الدقيقة

تعيد واجهة برمجة التطبيقات (API) سلاسل short_description وlong_description الدقيقة هذه لكل خطر:

واجهة API المستقلة لكشف الحيوية السلبي

تعيد Liveness API المستقلة استخدام رموز المخاطر نفسها مع بعض الاختلافات في السلوك:
  • الرمزان NO_FACE_DETECTED وLOW_LIVENESS_SCORE متنافيان — لا يُجرى فحص الدرجة إلا عند العثور على وجه. ينطلق الرمز LOW_LIVENESS_SCORE بناءً على face_liveness_score_decline_threshold الخاص بالطلب (القيمة الافتراضية 30) ويحمل دائماً log_type: "error".
  • يُعامل POSSIBLE_FACE_IN_BLOCKLIST كحالة رفض (log_type: "error") بدلاً من المراجعة.
  • يحمل MULTIPLE_FACES_DETECTED القيمة log_type: "warning"، بينما تظل مخاطر تكرار الوجه معلوماتية فقط. تؤدي التحذيرات بمستوى error فقط إلى تحويل status للاستجابة المستقلة إلى Declined.
  • تتضمن مدخلات التحذيرات المستقلة الحقل feature ولكن بدون node_id.

أمثلة

الرفض التلقائي عند اكتشاف هجوم

تحذيرات قابلة للتكوين في الالتقاط السلبي

وجه مكرر مع payload

هنا تم ضبط إجراء الوجه المكرر على مراجعة (Review)، لذا يحمل التحذير log_type: "warning" وتكون حالة تقرير كشف الحيوية In Review. مع الإجراء الافتراضي (بدون إجراء)، كان سيحمل log_type: "information" بدلاً من ذلك. تكون قيمة api_service هي null لأن الوجه المطابق جاء من جلسة سير عمل، وليس من استدعاء API مستقل.

وجه مكرر باسم مختلف

يبقى DUPLICATED_FACE عند الإجراء المُكوَّن له (هنا، بدون إجراء — log_type: "information") بينما يحمل DUPLICATED_FACE_NAME_MISMATCH الإجراء الخاص به، والذي يكون افتراضياً مراجعة (log_type: "warning"). تتبع حالة تقرير كشف الحيوية الإجراء الأكثر شدة بين الاثنين: In Review هنا، حتى لو لم يكن إعداد الوجه المكرر العادي وحده سيُفعِّله.

شذوذ في سلامة التسجيل مع قياساته

يوضح هذا المثال أدلة إعادة التشغيل من تسجيل يحتوي على ثلاث نسخ من تسلسل متحرك. قيمة log_type هي information لأن الإجراء المُكوَّن هو NO_ACTION. لا تؤدي تشخيصات تسليم الإطارات، التي حُذفت من هذا المثال للاختصار، إلى تفعيل هذه النتيجة.

أنواع التحذيرات

يتم تعيين مستوى شدة لكل خطر بناءً على تكوين تطبيقك. مستويات الشدة الثلاثة هي:

مواضيع ذات صلة

آخر تعديل في ٧ نوفمبر ٢٠٢٦