تصميم:طبلس
تطبيق متابعة حالات المأسورين (طبلس)
المشكلة
في لحظات الأزمات و الطوارئ تنشأ الحاجة إلى الجمع السريع لأسماء المخطوفين و المعتقلين و المختفين من النشطا في الشوارع و من البيوت.
جهود الإبلاغ عن الأسماء و ملابسا الاختفاء تتداولها شبكات من النشطاء المتكفلين بإدارة العملية معلوماتيا و قانونيا، و هذه المعلومات ترد في شكل تقارير و بلاغات مقتضبة، عادة ما تحوي أسماء تقريبية أو كُنى و\أو أماكن الاعتقال أو شهادات على اعتقال أشخاص غير معروفة أسماؤهم في ملابسات معينة، و عادة ما تكون في شكل طلبات للتيقّن و التوكيد.
البلاغات الواردة في صفحات فيسبوك قد تكون مكررة، و قد يرد بعضها واصفا وقائع بغير الترتيب الزمني الفعلي لها كما تجري عليها معالجات فيسبوك المجهولة التي تحدد درجة بروزها أو اختفائها في مجرى سيل البوستات. و المعلومات الواردة في البلاغا و التقارير
التطبيق
تطبيق خادوم\عميل فيه يتّصل العملاء بخادوم مركزي يضم قاعدة البيانات و يتولّى /الاستيثاق
- المستخدمون
- يعملون في مجموعات كلّ أعضاء المجموعة متساوون في الصلاحيات
- مدير النظام هو من يتولى إنشاء المجموعات و إضافة أعضاء إليها (مبدئيا لتسهيل نموذج الإدارة)
- المنظور الأساسي للتطبيق
- قائمة أسماء الأشخاص المفقودين الذين لا تزال حالاتهم مفتوحة، يمكن ترشيحها (فلترتها) بحسب مقاطع الاسم، مع حقل لإنشاء مدخلة باسم شخص جديد، بواجهة شبيهة بقوائم المعارف في تطبيقات التواصل
- يمكن لأي مستخدم فعل التالي
-
- إنشاء مدخلة جديدة باسم شخص ورد إلى علمه كونه مختفيا (مع وظيفة الاستكمال التلقائي للأسماء لتقليل احتمالات تكرار المدخلات)
- زيادة بيانات عن الشخص، مثل صورته، و وصف واقعة اختطافه و تاريخها، و حالته الصحية، و اسم المسؤول عن متابعة حالته، كلّ منها في حقل منفصل للتمييز و سهولة المطالعة
- تغيير الحالة الأخيرة المعلومة من اختيارات أساسية أو "أخرى" تدخل يدويا. الاختيارات قد تكون مثل "معتقل في ..." و "أخلي سبيله" إلخ، مع مؤشر نسبة اليقين من ثلاث درجات: أكيد، احتمال كبير، احتمال ضعيف
- ربط مدخلتين ببعضهما إذا ما اتضّح ورود بلاغين عن نفس الشخص باسمين مختلفين
- كل التغييرات التي يجريها المستخدمون منسوبة إلى أسمائهم
- منظور ثانوي للتطبيق
- تصفّح الوقائع بتواريخ وقائع الاختطاف
- منظور ثانوي آخر للتطيق
- التصفح بالحالة: "موجود في ..." أو "أخلي سبيله"، إلخ لأجل التعرف على الملفات المفتوحة
يحبّذ وجود نسخة من التطبيق للمحمول و نسخة للمتصفّحات.
مخاطر لا بد منها
- يمكن للمندسين أو عملاء الأجهزة الأمنية تخريب البيانات أو تشويشها، لكن عوضا عن تصميم نموذج لصلاحيات المستخدمين فإن التطبيق لأجل تبسيط استعماله يفترض علاج المسائل الأمنية بشريا بطريق الاستبعاد من المجموعة، لا بطريق إيجاد أدوات تحكّم لمستخدمين مختارين
- إمكانية استخدام التطبيق نفسه من قبل الأجهزة الأمنية أو المواطنين المؤيدين للسلطة لجمع بيانات عن النشطاء و استهدافهم: ربما يمكن الحد منه مبدئيا بطريق التحكم في اتّصال التطبيق بقاعدة البيانات المركزية بطريق إصدار دعوات فريدة لأفراد المجموعات المرغوب دعمها؟
تفاصيل تقنية
- الكيان الأساسي هو حالة الاختفاء لا اسم المختفي، لأن الشخص الواحد قد يكون موضوع عدّة حالات في أزمنة مختلفة
- اتّصال التطبيق بخادوم قاعدة البيانات يجب أن يكون معمّى
- اتّصال التطبيق بالخادوم يفضّل أن يكون عبر شبكة تور لإخفاء موضع الخادوم
- بيانات التطبيق المحفوظة محليا لدى العميل يجب أن تكون معمّاة، و مفتاح التعمية يكون محميا بعبارة سرّ تُطلب في كل فتح للتطبيق (ربما كل إظهار للتطبيق؟)
- استيثاق نبائط المستخدمين يكون بطريق شهادات رقمية موقّعة من الخادوم، تحوي أسماء المجموعات المنخرط فيها المستخدم و عنوان بريده.
- توجد آلية لنقض شهادة النبيطة (في حال ضياعها مثلا) بطريق إرسال رسالة بريد إلكتروني بمحتوى محدد إلى عنوان محدد (على أن يكون تصميم الآلية منحازا للأمان (fail-secure)؛ و ينبغي أن يطلب الخادوم من العميل محو مفتاح تعمية البيانات المخزنة محليا فور أوّل تواصل بين العميل و الخادوم.
إطار المشروع
مطلوب إطلاق إصدارة تجريبية من التطبيق في غضون أسبوع كتطبيق للمحمول، تليها إصدارة للمتصفّح
