في ضوء قوانين SESTA/FOSTA، التي تُزيل فعليًا العديد من الحماية لمديري مواقع الويب الاجتماعية/المنتديات/المحتوى الذي ينشئه المستخدمون (الملاذ الآمن بموجب القسم 230)، مما يجعل مديري المواقع مسؤولين عن أفعال مستخدمينهم.
قد يكون من الحكمة دعم استخدام واجهة برمجة تطبيقات للتعرف على الصور كحل واحد لتعزيز الحماية. وذلك لأتمتة حظر رفع المحتوى الصريح مثل (المحتوى غير الآمن، العري، العنف الدموي، إلخ).
كما يمكن تعزيز الحماية من الثغرات مثل رفع صور غير لائقة في المسودات، ثم ربطها حرارياً (hotlinking) من مواقع أخرى لاستخدامها كاستضافة صور مجهولة مجانية. لست متأكدًا من مدى قابلية استغلال هذه الفجوة في نظام Discourse، لكن يبدو أنه مع الإعدادات الافتراضية، يمكن استغلالها لمدة 180 يومًا بعد إنشاء المسودة دون أن يعلم مدير الموقع بما تم رفعه (حذف المسودات الأقدم من n يوم).
سيكون من الرائع جدًا فحص جميع الصور التي يتم رفعها إلى Discourse عبر Google Cloud Vision API لضمان السلامة من Adsense. لقد قمنا بذلك على موقعنا السابق ولم يتم رفع أي صور عارية أو دموية أبدًا.
توفر Google مكتبة Ruby (Gem):
يجب أن يتصل المكوّن الإضافي المحتمل بعملية رفع الصور الرئيسية في Discourse لجميع الصور (المشاركات، الصور الرمزية، خلفيات الملفات الشخصية، إلخ)، ويرفض الصور التي تحتوي على محتوى غير مسموح به:
حسنًا، أعتقد أن عملية رفع الصور المضمنة غير متزامنة بالفعل، كما أن واجهة برمجة تطبيقات Google سريعة جدًا.
من ناحية أخرى، سأكون سعيدًا أيضًا بفحص الصور بعد أن ينشر المستخدم منشورًا جديدًا عبر Webhook خارجي (واجهة برمجة تطبيقات Discourse)، وتعديل منشور المستخدم (على سبيل المثال، تغيير الصورة واستبدالها بالنص “تمت إزالة الصورة بواسطة المشرف”). يبدو أن هذا الجزء ممكن باستخدام الواجهة، لكنني لا أستطيع العثور على أي مرجع يوضح كيفية حذف الصورة “السيئة” فعليًا عبر الواجهة في مثل هذه الحالة، لأنني لا أرغب حتى في الاحتفاظ بها في مكان ما في الظل.
يسعدني العمل على هذا المشروع كمهمة مدفوعة. هل يمكنك المساعدة في جانب واجهة برمجة التطبيقات، أي تحديد الواجهة المستخدمة لكشف المحتوى المسيء وما إلى ذلك؟
@Terrapop - قد ترغب في أخذ دقة التعرف في الاعتبار. قد يكون من الجيد القدرة على رؤية بعض المحتوى الذي تم حظره، للتأكد من أنه ليس مُعدًا بشكل صارم للغاية من حيث ‘POSSIBLE’ و’LIKELY’ و’VERY_LIKELY’. فالنتائج الإيجابية والسلبية الخاطئة شائعة جدًا.
أعتقد أن التنفيذ الأفضل قد يكون إرسال أي منشورات تتضمن صورًا فوق مستوى معين من ‘البالغ المحتمل’ إلى قائمة المراجعة. بحيث لا يكون المنشور عامًا أبدًا، ولكن يمكنك الموافقة عليه إذا لم يكن التعرف دقيقًا. إذا تم رفضه من هناك، فسيتم حذف الصور، أعتقد بعد فترة زمنية وفقًا لما هو مُعد في ‘clean_orphan_uploads_grace_period_hours’.
هذا سيسمح باستخدام مستوى الكشف ‘POSSIBLY’ بثقة أكبر.
لقد اختبرنا واجهة برمجة التطبيقات (API) على موقعنا الحالي، ونعرف المستويات التي تناسبنا جيدًا.
يقوم @fzngagan بتطوير الإضافة مفتوحة المصدر لنا، لذا بمجرد الانتهاء منها، يمكنك تعديلها وتقديم طلب سحب (pull request) لإضافة خيار عدم الرفض المباشر، بل تحويل الطلب إلى قائمة المراجعة الخاصة بالمحررين.
إذا كان ذلك اختياريًا كإضافة إضافية، فأنا موافق على ذلك بالطبع.
لقد استخدمنا واجهة برمجة التطبيقات في مجتمعنا السابق لفترة طويلة ونعرف المستويات المقبولة لدينا. وفي معظم الأحيان، كانت واجهة برمجة التطبيقات صحيحة في الرفض، ويقوم المستخدم ببساطة برفع صورة أقل خطورة بدلاً من ذلك.
أيضًا، أردت فحص المنشورات بالإضافة إلى رفع الصور لصور الرموز والخلفيات الشخصية. لا أعرف ما إذا كان خيار الطابور ممكنًا لهذه أيضًا؟
