هل يحتاج تطبيق الأطفال إلى حساب فعلًا؟

ما السؤال الذي نسأله قبل حماية بيانات الطفل؟

السؤال المعتاد كيف نحمي بيانات الطفل بعد جمعها، والسؤال الذي يجب أن يُسأل أولًا لماذا جمعناها من الأصل. فكل حقل بيانات لا يُجمع أصلًا لا يحتاج تشفيرًا ولا سياسة احتفاظ ولا خطة استجابة لو تسرّب، لأنه غير موجود في أي مكان يمكن أن يُسرَّب منه. وهذا ليس بديلًا عن أمن المعلومات، بل خطوة تسبقه: ما لا نملكه لا نحتاج أن نحرسه.

نطرح هذا السؤال على كل حقل بيانات نطلبه في أي تسجيل موجّه لطفل: اسم حقيقي، أو تاريخ ميلاد دقيق، أو رقم هاتف، أو موقع جغرافي. والسؤال الواحد الذي يحسم الأمر بسيط: ماذا يتعطل في المنتج فعلًا إن لم نجمع هذا الحقل؟ فإن كان الجواب لا شيء، فهذا حقل يُجمع لغرض آخر غير خدمة الطفل، ويجب أن يُحذف من شاشة التسجيل بصرف النظر عن سهولة إضافته.

لماذا لا تكفي حماية البيانات وحدها؟

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

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

كيف تبدو شجرة القرار لكل عنصر بيانات؟

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

هذه الشجرة تحول نقاشًا مفتوحًا يطول بلا نهاية إلى قرار محدد لكل حقل بمفرده، بدل أن يُحسم الأمر دفعة واحدة بجملة عامة مثل «نجمع أقل قدر ممكن من البيانات» تبقى بلا أثر عملي إن لم تُطبَّق حقلًا بحقل.

ماذا يعني هذا لتصميم شاشة التسجيل؟

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

ويعني ثالثًا أن الحقول التي تبدو صغيرة، كخانة البريد الإلكتروني «لإرسال تنبيهات مفيدة»، تحتاج نفس السؤال بلا استثناء. فإن كان التنبيه نفسه يمكن أن يظهر داخل التطبيق حين يفتحه ولي الأمر، فهذا حقل بريد يُحذف لا يُبرَّر ببساطة استعماله المتوقع.

كيف يبدو نمط جيد ونمط مضاد لطلب البيانات؟

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

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

كيف تستعمل لوحة تقليل البيانات على تطبيقك؟

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

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

ما الذي لا تحسمه هذه اللوحة؟

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

من أين تبدأ؟

افتح شاشة التسجيل في منتجك الحالي، واكتب كل حقل تطلبه على ورقة منفصلة، ثم اسأل عن كل حقل السؤال نفسه: ماذا يتعطل فعلًا إن حذفناه؟ جرّب لوحة تقليل البيانات لتنظيم الإجابات، واقرأ أيضًا كيف نترجم مبادئ السلامة إلى قرارات تصميم ملموسة وكيف يفحص الأهل بأنفسهم بيانات أي تطبيق موجّه لطفلهم. ويمكنك أن تحكي لنا عن منتجك من نموذج «ابدأ مشروعًا».

مراجع

• موقفنا من السلامة، وتفصيل التزام قلة البيانات منه: صفحة السلامة عندنا، منشور داخلي من دواني.
• إطار دواني للتصميم الآمن للطفل: إطار داخلي مستقل من دواني، لا معيار حكومي.

أسئلة سريعة

هل غياب الحساب الشخصي يعني غياب أي بيانات عن الطفل؟

لا بالضرورة. بعض المنتجات تحتاج حفظ تقدم أو تفضيلات، لكنها تستطيع فعل ذلك بأقل تفصيل ممكن، أو مرتبطة بحساب ولي الأمر لا بحساب مستقل للطفل.

ماذا نفعل حين يطلب فريق التسويق حقل بيانات إضافيًا؟

نطبّق السؤال نفسه على طلبهم: ماذا يتعطل في المنتج، لا في خطة التسويق، إن لم نجمع هذا الحقل؟ حاجة تسويقية بحتة لا تكفي وحدها لتبرير جمع بيانات طفل.

هل تختلف الإجابة إن كان المستخدم يافعًا لا طفلًا صغيرًا؟

نعم، فبعض اليافعين يحتاجون قدرًا من الاستقلالية في حسابهم يختلف عن طفل صغير، لكن السؤال التأسيسي نفسه يبقى: ماذا يتعطل فعلًا إن قلّلنا هذا الحقل بعينه؟