اقتراح الأصدقاء والأشخاص للأطفال: كيف نمنع الخوارزمية من فتح باب الغرباء؟

ميزة من قد تعرفه أو Suggested for you تبدو اجتماعية وبسيطة، لكنها بالنسبة لطفل قد تتحول إلى قناة وصول جديدة لم يكن سيبحث عنها بنفسه. نظام اقتراح الأشخاص يقرر أي حسابات تظهر أمام الطفل وأمام من يظهر حساب الطفل، وقد يستخدم الأصدقاء المشتركين أو جهات الاتصال أو الموقع أو المدرسة أو الاهتمامات أو مجموعات مشتركة أو سلوك مشاهدة. عندما يكون أحد الطرفين بالغًا أو مجهولًا أو ذا تاريخ سلوك خطِر، فإن توصية الاتصال ليست مجرد عرض محايد؛ إنها تدخل تصميمي يخلق فرصة تواصل. لذلك يجب تقييمها كجزء من حماية الطفل لا كجزء منفصل من growth. الهدف ليس منع الأطفال من تكوين صداقات، بل جعل اكتشاف الأشخاص متناسبًا مع العمر والعلاقة والسياق وتقليل فرص أن تفتح الخوارزمية بابًا لمعتدٍ أو محتال أو شخص يلاحق الطفل.

ما الفرق بين توصية المحتوى وتوصية الأشخاص؟

توصية فيديو قد تعرض الطفل لمحتوى ضار، أما توصية شخص فقد تنشئ علاقة يمكن أن تنتقل إلى DM أو مكالمة أو لعبة أو لقاء. الخطر تفاعلي ومتراكم. لذلك لا يكفي تطبيق نفس ranking model مع استبدال video_id بـuser_id. يجب أن يدخل في القرار عمر الطرفين، نوع العلاقة المحتملة، تاريخ الحساب، سلوك الاتصال، الحظر السابق، mutual graph، وقيود الخصوصية. وقد يكون القرار الصحيح عدم اقتراح أي شخص في بعض الحالات بدل محاولة اختيار الأقل خطورة.

الاقتراح نفسه إشارة ثقة

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

الأطفال والبالغون: لا تجعل العمر متغيرًا صغيرًا في النموذج

عند حساب قاصر، يجب أن يكون فرق العمر قيدًا أساسيًا لا feature ثانوية يمكن أن يتغلب عليها engagement score. في كثير من الخدمات لا توجد حاجة مشروعة لاقتراح بالغ مجهول لطفل. إذا كان هناك سياق تعليمي أو عائلي أو مهني حقيقي، استخدم علاقة موثقة أو قناة مؤسسية بدل friend suggestion عام. اجعل adult-to-child recommendations محظورة افتراضيًا أو مقيدة بشدة، مع استثناءات مبررة وقابلة للتدقيق.

العمر غير المؤكد

إذا كانت المنصة غير واثقة من العمر، لا تعامل الحساب كعضو بالغ تلقائيًا في graph discovery. استخدم نطاقات ثقة وsafe fallback. حساب يدعي 19 عامًا لكن لديه مؤشرات قوية على كونه أصغر قد يحتاج حماية مؤقتة، بينما لا يجب حذف الحساب فورًا بناء على inference واحد. افصل إجراءات حماية الاكتشاف عن إجراءات enforcement الأعلى أثرًا؛ يمكن تقليل ظهور الاقتراحات أثناء المراجعة دون اتهام المستخدم.

الأصدقاء المشتركون لا يثبتون الأمان

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

جهات الاتصال: رفع دفتر الهاتف ليس موافقة على أن يصبح الطفل قابلًا للاكتشاف

ميزة العثور على أصدقاء عبر contacts قد تكشف أن رقم طفل مرتبط بحساب، أو تجعل بالغًا لديه الرقم لأي سبب يرى الحساب. افصل بين استخدام دفتر الهاتف للبحث المحلي وبين رفعه وتخزينه أو إنشاء social graph. لا تجعل حساب الطفل discoverable by phone افتراضيًا. إذا اختار الطفل أو الأسرة المزامنة، وضح ما الذي سيرفع ومدة الاحتفاظ وكيف يمكن الإلغاء والحذف.

المدرسة والصف والموقع كإشارات حساسة

اقتراح أشخاص لأنهم في المدرسة نفسها أو الموقع نفسه قد يساعد التواصل لكنه يخلق خطر كشف هوية ومكان القاصر. لا تستخدم precise location أو routine أو شبكة المدرسة لتوصية الغرباء. إذا كانت هناك ميزة campus أو class، اجعلها داخل مساحة موثقة ومغلقة بحدود المؤسسة. لا تعرض للبالغ أن هؤلاء أطفال بالقرب منك أو طلاب في مدرسة محددة.

المجموعات المشتركة والمجتمعات

عضوية الطفل في مجموعة ألعاب أو fandom لا تعني أنه يريد اتصالًا خاصًا بكل الأعضاء. لا تحول co-membership تلقائيًا إلى friend suggestions، خصوصًا في مجتمعات كبيرة أو حساسة. استخدم privacy controls تسمح للطفل بالمشاركة في المجتمع دون أن يصبح profile قابلًا للاكتشاف خارج النقاش. وعند المجموعات المرتبطة بالصحة أو الهوية أو الدعم، تعامل مع membership كإشارة حساسة لا كميزة نمو.

من يرى الطفل أهم من من يراه الطفل

يمكن للمنصة أن تحمي feed الطفل ومع ذلك تعرض حسابه لمئات البالغين في اقتراحاتهم. لذلك audit يجب أن يكون ثنائي الاتجاه: ما الأشخاص الذين نوصي بهم للطفل، ولمن نوصي بالطفل؟ افحص exposure count وخصائص الجمهور المستلم، لا clicks فقط. قد تحتاج إلى منع حسابات القاصرين من الظهور في friend suggestions للبالغين غير المرتبطين حتى لو لم يكن الطفل يرى هؤلاء البالغين.

الحسابات الجديدة والاقتراحات السريعة

حساب جديد بلا تاريخ لا ينبغي أن يحصل فورًا على قائمة واسعة من القاصرين لإضافتهم. استخدم ramp-up وحدودًا على outgoing requests والتوصيات، خصوصًا إذا كانت العلاقة بالعمر غير واضحة. لا تعاقب المستخدم الجديد الشرعي بمنعه من كل تواصل؛ اسمح بإيجاد جهات موثوقة أو رموز دعوة مباشرة، لكن لا توفر discovery واسعًا قبل بناء إشارات ثقة.

الحساب الذي يرسل عشرات الطلبات إلى قاصرين

سلوك mass friending إشارة خطر مهما كان محتوى الرسائل غير معروف. راقب نسبة الطلبات المقبولة، الأعمار المستهدفة، السرعة، التكرار بعد الرفض، والانتقال من friend request إلى DM. ضع rate limits وfriction وreview. لا تجعل model ranking يكافئ الحساب لأنه يحصل على ردود كثيرة إذا كان ذلك نتيجة ضغط أو استهداف.

الحظر والرفض يجب أن يغذيا نظام التوصية

إذا حظر طفل شخصًا أو رفض طلبه، يجب ألا يعود النظام ويقترح الحساب نفسه أو حسابًا مرتبطًا به فورًا. استخدم negative feedback بصورة واضحة، مع حماية من إساءة استخدام الحظر كسلاح ضد الآخرين. لا تعرض للمرسل سبب عدم ظهوره أو تفاصيل تسمح له باستنتاج أن الطفل حظره. راقب re-entry عبر حسابات جديدة دون تحويل device linking إلى حكم نهائي بمفرده.

اقتراح شخص ثم فتح DM تلقائيًا يضاعف الخطر

افصل discovery عن messaging permission. قبول follow أو مشاهدة profile لا يجب أن يفتح تلقائيًا الصور أو المكالمات أو location sharing. للقاصرين، اجعل انتقال العلاقة على مراحل مع controls مستقلة: follow، friend، DM، attachments، voice/video. كل مرحلة تحتاج default مناسبًا وعرضًا واضحًا لما سيتغير.

الصور والملفات في أول اتصال

حتى عندما يسمح النظام لغير المعروف بإرسال طلب، يمكن منع attachments أو طمسها حتى يقبل الطفل العلاقة. هذا يقلل cyberflashing ومحتوى الصدمة. لا تجعل الطفل يفتح الصورة ليرى هل الحساب آمن. اربط حماية media مع contact recommendation وDM policy، لأن الخطر لا يعيش في نظام واحد داخل المنتج.

التوصيات المبنية على الاهتمامات الحساسة

إذا شاهد الطفل محتوى عن اكتئاب أو هوية أو مشاكل أسرية، لا تستخدم ذلك لاقتراح أشخاص غرباء يدّعون الدعم. يمكن توصية خدمة موثوقة أو محتوى آمن، لكن user-to-user matching في سياق ضعف يحتاج حوكمة أشد. لا تجعل الاستنتاج النفسي مدخلًا لاكتشاف بالغين أو مجتمعات قد تستغل الطفل.

الاقتراحات بعد حادث استغلال

بعد بلاغ grooming أو sextortion أو stalking، راجع social recommendations مؤقتًا: هل ما زال حساب الطفل يظهر لأشخاص من شبكة المعتدي؟ هل تقترح المنصة حسابات مرتبطة بالمجموعة نفسها؟ يمكن تفعيل safety mode يقلل discoverability والطلبات الجديدة لفترة يختارها الطفل، مع عدم عزل حسابه عن أصدقائه الحاليين. الهدف قطع مسار الوصول لا محو الحياة الاجتماعية.

الأطفال ذوو الإعاقة والبحث عن الأقران

ميزة إيجاد أقران ذوي خبرة مشابهة قد تكون مفيدة، لكنها قد تكشف الإعاقة أو الاحتياج وتعرض الطفل للاستغلال. استخدم مساحات moderated أو مؤسسات موثوقة بدل نشر profile إلى غرباء بناء على diagnosis. اشرح للطفل ولمقدم الدعم لماذا يظهر الشخص، ولا تجعل الاحتياج للدعم سببًا لتوسيع exposure.

الصداقة ليست KPI مستقلًا عن السلامة

إذا كان فريق النمو يقيس accepted requests فقط، قد يدفع model إلى اقتراح علاقات ذات احتمال قبول مرتفع لكنها غير آمنة. أضف metrics مثل blocks بعد recommendation، reports، age-gap contacts، DM escalation، attachment abuse، repeated rejection، ووقت بقاء العلاقة قبل الحظر. خفّض وزن engagement إذا ارتبط بنتائج ضرر.

قياس Exposure قبل Click

لا تنتظر أن يضغط الطفل على profile كي تسجل الخطر. مجرد ظهور حساب طفل في carousel بالغين أو ظهور بالغ خطِر أمام آلاف القاصرين هو exposure يجب قياسه. أنشئ denominator واضحًا: عدد توصيات adult-to-child، عدد child profiles shown to unknown adults، ونسبة هذه الحالات التي انتهت باتصال أو report. هذا يكشف المخاطر قبل أن تتحول إلى محادثات.

Protective defaults: ماذا نعرف من 2026؟

Ofcom نشر في يوليو 2026 تجربة عشوائية أظهرت دعمًا قويًا واحتفاظًا مرتفعًا بإعدادات اجتماعية أكثر حماية عند جعلها افتراضية. هذا يدعم فكرة أن default الآمن لا يعني بالضرورة أن المستخدمين سيرفضونه. استخدم private profile وcontact limits وreduced discovery كبداية للقاصرين، ثم اسمح بتغييرات مفهومة ومتناسبة مع العمر.

إجراءات Ofcom ضد خطر الغرباء في 2026

في مايو 2026 أعلن Ofcom أن Snap وMeta وRoblox التزمت بإجراءات إضافية لحماية الأطفال من الغرباء، منها إعدادات أشد للاتصال ومجموعات الصداقة وأدوات كشف وضوابط chat. لا يعني ذلك أن نموذجًا واحدًا يصلح لكل منصة، لكنه يثبت أن contact architecture جزء مباشر من مكافحة grooming وليس ميزة اجتماعية محايدة.

ما الذي يجب أن يستطيع الطفل التحكم به؟

1. من يمكنه إرسال friend request أو follow.
2. هل يظهر حسابه في suggestions للغرباء.
3. هل يمكن العثور عليه بالهاتف أو البريد.
4. هل school أو location أو group membership تدخل في الاكتشاف.
5. من يستطيع DM بعد follow أو friend.
6. هل المرفقات والصور مسموحة في أول اتصال.
7. كيف يحظر ويمنع إعادة الاقتراح.
8. كيف يرى سبب ظهور اقتراح بصورة مبسطة.
9. كيف يوقف discovery مؤقتًا بعد حادث.
10. كيف يحذف contacts المرفوعة ويوقف مزامنتها.

اختبار النظام قبل الإطلاق

أنشئ test matrix لأعمار مختلفة: طفل 12، مراهق 15، بالغ 25، حساب جديد، حساب موثوق، وحساب له reports. اختبر كل اتجاه pairwise: من يقترح لمن؟ أضف mutual friend، shared group، same school، same location، uploaded contact ثم راقب هل الحواجز تبقى. اختبر حظرًا ورفضًا وحسابًا يعود. لا تستخدم بيانات أطفال حقيقية في sandbox؛ أنشئ accounts اصطناعية وحالات مراقبة.

التدقيق ضد الانحياز

قد تقلل safeguards الوصول لأطفال في مناطق أو لغات أو فئات أكثر من غيرهم، أو قد تخطئ age inference بسبب bias. قِس false restrictions وunsafe exposures عبر مناطق ولغات وأجهزة. لا تجعل safety model سببًا لعزل فئة من تكوين صداقات مشروعة. وفر appeal للإجراءات العالية الأثر، لكن لا تكشف قواعد يمكن للمعتدين استخدامها للتحايل.

خطة 90 يومًا لإصلاح Social Discovery

خلال 30 يومًا ارسم كل surfaces التي تقترح أشخاصًا أو تجعل الطفل قابلًا للاكتشاف، مع features المستخدمة. خلال 31 إلى 60 يومًا طبّق adult-child constraints، private defaults، negative feedback، attachment limits وrate limits. خلال 61 إلى 90 يومًا أضف exposure metrics، اختبارات synthetic، مراجعة school/location/contact signals، وtabletop لحساب بالغ يبني شبكة قاصرين. أعد المراجعة عند تغيير graph model أو age assurance.

نموذج روافد المفاهيمي: حاجز الاتصال المقترح

تقترح روافد خمسة محاور قبل اقتراح علاقة: عمر الطرفين وثقة العمر، دليل العلاقة أو السياق، تاريخ السلوك والرفض، حساسية الإشارة التي صنعت الاقتراح، وما الذي سيفتحه القبول من قنوات. النموذج conceptual وغير متحقق. يمكن اختباره بقياس adult-child exposure وblocks وreports بعد recommendation ونجاح العلاقات المشروعة. الهدف ألا يصبح ranking score قادرًا على تجاوز قيد حماية أساسي لمجرد احتمال engagement أعلى.

أسئلة شائعة

المصادر والمنهجية

تعتمد الصفحة على موقف eSafety في مايو 2026 الذي يذكر خطر توصية الشباب بأشخاص أو مجتمعات غير آمنة، وإرشاداته التنظيمية في فبراير 2026 التي تدعو إلى توصيات صديقة للعمر تشمل friend/follower suggestions، وإعلان Ofcom في مايو 2026 عن تدابير إضافية لمكافحة grooming، وتجربته في يوليو 2026 عن protective defaults، ومعايير ICO بشأن profiling وfriend suggestions، وتحديث Children’s Code حول الطلبات والرسائل من الغرباء. جرى فصل هذا intent عن recommender systems للمحتوى وعن سياسة الرسائل نفسها والتركيز على social graph وexposure ثنائي الاتجاه.

البحث اليدوي ليس مثل الاقتراح الآلي

إذا كتب الطفل اسم مستخدم يعرفه وبحث عنه، فهذه مبادرة منه تختلف عن أن تدفع المنصة أمامه عشرات الحسابات من دون طلب. لذلك يمكن أن تكون قواعد search أكثر سماحًا من recommendation في بعض السياقات، مع بقاء حماية العمر والخصوصية. لا تستخدم القدرة على البحث عن شخص كحجة لعرضه تلقائيًا في carousel. وبالعكس، إذا كان الحساب غير قابل للبحث لأسباب حماية، فلا ينبغي أن يتسرب عبر الاقتراحات أو نتائج typo أو auto-complete.

Gaming للـSocial Graph: المعتدي قد يعلّم النظام أنه قريب من الطفل

يمكن لشخص أن يتبع حسابات قريبة من الطفل، ينضم إلى مجموعاته، يحفظ جهات اتصال عامة أو يتفاعل مع المحتوى نفسه حتى يرفع احتمال ظهوره في التوصيات. لذلك افحص adversarial behavior عند تصميم graph features. لا تسمح لمجرد زيادة mutuals أو co-memberships خلال وقت قصير أن يصنع trust score قويًا. ضع decay وquality weighting وإشارات لعمر الحساب والرفض والحظر، واختبر كيف يستطيع حساب خبيث أن ينتقل من لا صلة إلى موصى به خلال أيام.

Directory المدرسة ليس قائمة أصدقاء عامة

إذا ربطت المدرسة منصة تعليمية بدليل الطلاب، استخدم directory للوصول الأكاديمي المصرح به لا لتحويل كل طالب إلى اقتراح اجتماعي. افصل حساب المعلم عن friend model، ولا تعرض طلاب صف كامل لحساب بالغ خارج المؤسسة. عندما يغادر الطالب المدرسة أو ينتقل صفه، حدّث الصلاحيات والروابط فورًا. لا تجعل بريد المدرسة أو domain وحده إثبات علاقة اجتماعية تسمح برسائل أو ملفات شخصية.

دعوات QR والروابط لا يجب أن تعيد فتح الاكتشاف العام

يمكن أن يستخدم الطفل رابطًا أو QR للانضمام إلى صديق أو فريق، لكن قبول دعوة محددة لا يعني الموافقة على أن يصبح حسابه discoverable لكل أعضاء الشبكة أو أصدقاء أصدقائهم. اربط الدعوة بنطاق واضح ومدة انتهاء وعدد استخدامات عند الحاجة. إذا تسرب الرابط، يجب أن يستطيع المشرف إبطاله. لا تجعل الانضمام إلى مجموعة عبر QR سببًا تلقائيًا لاقتراح كل الأعضاء كأصدقاء.

اللغة والمنطقة قد تغيّران مخاطر الاقتراح

نظام مدرب على سوق واحد قد لا يلتقط أسماء المدارس أو أنماط الاحتيال أو دلالات العمر في سوق آخر. اختبر العربية واللهجات والأسماء المستعارة والكتابة المختلطة، ولا تستخدم نقص بيانات moderation في لغة ما سببًا لتخفيف القيود. راقب إن كان model يوصي بحسابات بالغة للقاصرين أكثر في مناطق ذات age signals ضعيفة. safety constraint يجب أن يعمل قبل ranking المحلي لا بعده.

لماذا ظهر هذا الشخص؟ Explainability عملية وليست صفحة نظرية

يمكن أن يفيد المستخدم تفسير بسيط مثل لديكما أصدقاء مشتركون أو أنتما في نفس المجموعة، لكن لا تكشف معلومات حساسة مثل موقع قريب أو رقم هاتف محفوظ لدى الطرف الآخر. إذا لا تستطيع تفسير السبب دون كشف بيانات، قد يكون من الأفضل عدم عرضه. داخليًا يجب أن يحتفظ الفريق بـfeature attribution كافٍ للتحقيق: أي إشارات رفعت التوصية وهل تجاوزت قيد عمر أو privacy. لا تحتاج الواجهة كشف تفاصيل النموذج للمستخدم.

Kill switch عند اكتشاف نمط استهداف واسع

إذا ظهر أن recommender يقترح حسابًا بالغًا أو مجموعة حسابات على عدد كبير من القاصرين، يجب أن تستطيع المنصة إيقاف surface أو feature family سريعًا من دون انتظار إصدار تطبيق جديد. صمم feature flag وحدودًا آمنة، واحفظ قائمة بالحسابات المتأثرة لتقييم الخطر. بعد الإيقاف لا تعيد الخدمة لمجرد أن traffic انخفض؛ حدّد root cause واختبر fix على synthetic accounts ثم راقب exposure بعد العودة.

Appeal للقيود الاجتماعية دون كشف من أبلغ

قد تمنع الحماية حسابًا مشروعًا من الظهور أو تحد من طلباته. وفر appeal للحساب المتأثر إذا كان الإجراء عالي الأثر، لكن لا تخبره أن طفلًا محددًا حظره أو أبلغ عنه. راجع العمر والعلاقة وسجل السلوك، واستخدم reviewer للحالات الحدودية. لا تجعل appeal نفسه طريقًا للوصول إلى الطفل أو الحصول على بياناته. سجل reversal rate لفهم إن كانت قواعد adult-child أو age inference واسعة أكثر من اللازم.

Release gate لأي تغيير في People You May Know

قبل إطلاق model جديد، قارن adult-child exposure وchild-to-unknown exposure والblocks والتقارير مع baseline. اختبر حسابات قاصرين وبالغين وحسابات جديدة ومجموعة مشتركة ومدرسة ومزامنة contacts. لا تسمح بالإطلاق إذا زاد exposure عالي الخطورة حتى لو تحسن acceptance rate. ضع owner وthresholds وrollback واضحًا. كل feature جديد يدخل social graph، من proximity إلى AI matching، يجب أن يمر بنفس البوابة.

فصل نجاح الصداقة عن نجاح النموذج

لا تعتبر العلاقة ناجحة لمجرد قبول الطلب. راقب بقاء الاتصال دون block أو report، وهل تحول إلى DM آمن أم إلى ضغط ومرفقات غير مرغوبة. لكن لا تحول المراقبة إلى قراءة كل محادثة. استخدم إشارات مجمعة ومتناسبة مع الخصوصية، وراجع الحالات الخطرة عند البلاغ. الهدف معرفة إن كان recommender ينتج علاقات مفيدة فعليًا لا مجرد click-through مرتفع.

مراجعة بشرية للحسابات التي يظهر لها عدد كبير من القاصرين

أنشئ قائمة داخلية للحسابات التي يتكرر ظهورها في توصيات القاصرين أو ترسل طلبات إلى أعمار متعددة، ورتبها حسب exposure والرفض والحظر والتقارير. لا تعتبر الظهور المتكرر دليل إساءة بمفرده، لكنه يستحق مراجعة pattern خصوصًا عندما يجتمع مع حساب حديث أو فارق عمر أو re-entry. يجب أن يرى reviewer بيانات السلوك الضرورية لا محادثات خاصة كاملة، وأن يستطيع خفض discoverability أو إيقاف التوصيات مؤقتًا أثناء التحقيق. قِس كذلك false positives كي لا يتحول النظام إلى منع معلمين أو أقارب أو جهات دعم مشروعة بلا مسار واضح.

التغيير الصغير في Graph قد يخلق مسار وصول جديدًا

إضافة feature تبدو بسيطة مثل أصدقاء الأصدقاء أو قريبون منك أو أشخاص شاهدوا المحتوى نفسه قد تغير من يستطيع العثور على الطفل جذريًا. قبل إدخال أي edge جديد إلى social graph، اكتب threat model يشرح مصدر الإشارة، حساسيتها، عمرها، من يمكنه تصنيعها أو التلاعب بها، وكيف تتفاعل مع حدود العمر والحظر. اختبر feature منفصلة ومركبة مع بقية الإشارات؛ فقد تكون كل إشارة مقبولة وحدها لكن الجمع بين school + mutual + location يجعل هوية الطفل قابلة للاستنتاج. احتفظ بسجل تغييرات graph حتى يمكن ربط أي ارتفاع في grooming reports أو adult-child exposure بإصدار محدد.

ما بعد الحظر: لا تجعل توصيات الأصدقاء تكشف شبكة الطفل للمعتدي

بعد أن يحظر الطفل حسابًا، لا ينبغي أن يستفيد الحساب المحظور من قائمة الأصدقاء أو الاقتراحات لاكتشاف أقرب أصدقاء الطفل ثم محاولة الوصول إليه عبرهم. راجع friend-of-friend surfaces، قوائم المتابعين العامة، suggested contacts، وnotifications التي تقول انضم صديقك. يمكن تقليل graph leakage للحسابات المحظورة أو عالية الخطورة من دون إخفاء الحياة الاجتماعية عن الجميع. وإذا أبلغ الطفل عن stalking، فعّل إعدادات أشد مؤقتًا تشمل إخفاء الروابط الاجتماعية التي تساعد الشخص على إعادة بناء طريق إليه عبر أطراف ثالثة.