للعلم، فريق Chrome لم يفعل شيئًا حتى الآن.
لا تزال المشكلة قائمة في Chrome، ويمكننا إصلاحها ببساطة عن طريق استبدال مصيدة البريد المزعج الخاصة بنا بنوع من إثبات العمل.
إغلاق لمدة شهرين آخرين.
يبدو أن فريق Chrome حريص على إصلاح هذه المشكلة، لكنه يحتاج إلى سجلات هنا:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
سأحاول جمع بعض السجلات غدًا. إذا سبقتني أي شخص في ذلك، فأنت بطلي، يرجى الإشارة إلى هذه المشاركة.
تعديل … تم إرسال السجلات إليهم.
@codinghorror هذا الأمر يدور في حلقة مفرغة داخل جوجل. يقولون إن السلوك مقصود حسب التصميم، ولا يملكون طريقة دقيقة للكشف عما إذا كان حقل النص (textarea) مرئيًا أم لا.
الرد العام هنا هو: “من السهل جدًا على الروبوت تجاوز هذا الإجراء، فما الفائدة؟”. ليس لدي رد حقيقي هنا، فأنا أميل إلى الاتفاق معهم؛ فخانة الفخ (honeypot) تبدو سخيفة بعض الشيء، ويمكنني استبدالها بسهولة بشيء آخر يضمن أن المستخدم الذي يسجل حسابًا جديدًا يشغّل جافا سكريبت على الأقل.
لقد قضيت وقتًا طويلاً بالفعل في هذا الأمر، وأشعر وكأنني أحارب طواحين الهواء. أريد فقط تطبيق إصلاح ثم المضي قدمًا.
حسناً، لكنني أريد أن يكون دليلاً على العمل معقداً إلى حد ما. هل يوجد كود موجود يمكننا استخدامه؟
نعم، يمكنني إعداد شيء ما، وسيكون بالتأكيد أفضل من نظامنا الحالي. نظامنا الحالي لـ ‘إثبات العمل’ هو ‘عكس السلسلة’.
لقد قضيت وقتًا طويلاً للغاية في التفكير في هذه المشكلة، لذا قررت أنه حان الوقت لوضع حد لها:
وفقًا لهذا الالتزام (commit)، فإن المُشغِّل الأصلي (OP) هنا “تم إصلاحه”
الإصلاح معقد نوعًا ما وشمل جزأين يسعدني أنني تمكنت من إنجازهما.
-
شدّدت المنطق الخاص بـ honeypot والتحدّي بشكل كبير.
-
أضفت حلاً مؤقتًا يعمل فقط على جانب العميل لتصحيح خلل في Chrome يتعلق بالإكمال التلقائي، وأنا مرتاح لهذا الحل لأنه لا يغيّر أي شيء في بروتوكول جانب الخادم.
في السابق، كنا نعيد استخدام سلسلة عشوائية موحدة لـ honeypot والتحدّي لجميع تسجيلات الحسابات في الموقع، مما يجعل برمجة إنشاء الحسابات أمرًا تافهًا، حيث يكفي ترميز قيمة واحدة مرة واحدة.
أما التنفيذ الجديد فيعطي كل مستخدم سلسلة فريدة للتحقق منها، مرتبطة بمخزن ملفات تعريف الارتباط (في مخزن الجلسة الآمن لدينا). تنتهي صلاحية هذه السلسلة بعد ساعة واحدة.
وهذا يعني أنه عند برمجة هذه الأمور، يُجبر المرء على إجراء مكالمات منتظمة للحصول على تحديات و honeypots جديدة تمامًا بين الطلبات، ولا يمكن ببساطة إنشاء الحسابات دفعة واحدة.
الحل المؤقت في النقطة 2 هو ببساطة إعادة ترتيب حقل INPUT الذي يخلط عليه Chrome، واستبداله بحقل INPUT من نوع النص الذي لا يخلط عليه.
بشكل عام، لا أشعر أن النقطة (2) تجعل الأمر أسهل لأي بوت “عام” مُبرمج لتسجيل الحسابات في مواقع غير معروفة. أولاً، يجب أن يستخدم البوت محرك Chrome Web Driver، ويحلل جميع مكونات Ember لدينا، ثم يتبع تدفقًا محددًا للغاية. هذا الحاجز منخفض جدًا ولا يُقارن بالتحديات الدورية الجديدة لكل مستخدم.
أما فيما يتعلق بإضافة إثبات العمل (proof of work)، فأود الانتظار قليلاً، ليس لأن بناءه صعب بشكل خاص، بل لأنني لا أرغب في البحث عن أسرع خوارزمية SHA1 المتاحة ثم إرسالها إلى العميل عند الطلب.
سأترك هذا الموضوع مفتوحًا لفترة قصيرة حتى يتمكن الناس من التأكد من أن إصلاحاتي تحل المشكلة. وسأغلقه بعد أسبوع.