أدى التضمين الافتراضي لـ Idle Detection API في Chrome 94 إلى موجة من الانتقادات، نقلاً عن اعتراضات من مطوري Firefox وWebKit/Safari.
تسمح واجهة برمجة التطبيقات Idle Detection API للمواقع باكتشاف الوقت الذي يكون فيه المستخدم غير نشط، على سبيل المثال. لا يتفاعل مع لوحة المفاتيح/الماوس أو يؤدي العمل على شاشة أخرى. تسمح لك واجهة برمجة التطبيقات (API) أيضًا بمعرفة ما إذا كانت شاشة التوقف تعمل على النظام أم لا. يتم تنفيذ المعلومات حول عدم النشاط عن طريق إرسال إشعار بعد الوصول إلى حد عدم النشاط المحدد، والذي تم تعيين الحد الأدنى لقيمته على دقيقة واحدة.
من المهم ملاحظة أن استخدام Idle Detection API يتطلب منحًا صريحًا لأذونات المستخدم، أي. إذا حاول التطبيق اكتشاف عدم النشاط للمرة الأولى، فسوف تظهر للمستخدم نافذة تسأل عما إذا كان يجب منح الأذونات أو حظر العملية. لتعطيل Idle Detection API بشكل كامل، يتم توفير خيار خاص ("chrome://settings/content/idleDetection") في قسم إعدادات "الخصوصية والأمان".
تشمل مجالات التطبيق تطبيقات الدردشة والشبكات الاجتماعية والاتصالات التي يمكنها تغيير حالة المستخدم حسب تواجده على الكمبيوتر أو تأخير إشعار الرسائل الجديدة حتى وصول المستخدم. يمكن أيضًا استخدام واجهة برمجة التطبيقات (API) في تطبيقات الكشك للعودة إلى الشاشة الأصلية بعد فترة من عدم النشاط، أو لتعطيل العمليات التفاعلية كثيفة الاستخدام للموارد، مثل إعادة رسم المخططات المعقدة وتحديثها باستمرار، عندما لا يكون المستخدم على جهاز الكمبيوتر.
موقف المعارضين لتمكين Idle Detection API هو أن المعلومات حول ما إذا كان المستخدم موجودًا على الكمبيوتر أم لا يمكن اعتبارها سرية. بالإضافة إلى التطبيقات المفيدة، يمكن أيضًا استخدام واجهة برمجة التطبيقات هذه لأغراض سيئة، على سبيل المثال، لمحاولة استغلال الثغرات الأمنية أثناء غياب المستخدم أو لإخفاء نشاط ضار واضح، مثل التعدين. باستخدام واجهة برمجة التطبيقات المعنية، يمكن أيضًا جمع معلومات حول أنماط سلوك المستخدم والإيقاع اليومي لعمله. على سبيل المثال، يمكنك معرفة الوقت الذي يذهب فيه المستخدم عادة لتناول الغداء أو مغادرة مكان العمل. وفي سياق الطلب الإلزامي لإثبات التفويض، تعتبر Google هذه المخاوف غير ذات أهمية.
بالإضافة إلى ذلك، يمكنك ملاحظة ملاحظة مطوري Chrome حول الترويج لتقنيات جديدة لضمان التشغيل الآمن للذاكرة. بحسب جوجل فإن 70% من المشاكل الأمنية في كروم سببها أخطاء في الذاكرة، مثل استخدام المخزن المؤقت بعد تحرير الذاكرة المرتبطة به (استخدام بعد فراغ). تم تحديد ثلاث استراتيجيات رئيسية للتعامل مع مثل هذه الأخطاء: تعزيز عمليات التحقق في مرحلة التجميع، وحظر الأخطاء في وقت التشغيل، واستخدام لغة آمنة للذاكرة.
يُذكر أن التجارب بدأت في إضافة القدرة على تطوير مكونات بلغة Rust إلى قاعدة بيانات Chromium. لم يتم تضمين كود Rust بعد في الإصدارات المقدمة للمستخدمين ويهدف بشكل أساسي إلى اختبار إمكانية تطوير أجزاء فردية من المتصفح في Rust وتكاملها مع الأجزاء الأخرى المكتوبة بلغة C++. بالتوازي، بالنسبة لكود C++، يستمر المشروع في التطوير لاستخدام نوع MiraclePtr بدلاً من المؤشرات الأولية لمنع إمكانية استغلال الثغرات الأمنية الناتجة عن الوصول إلى كتل الذاكرة المحررة بالفعل، كما يتم اقتراح طرق جديدة لاكتشاف الأخطاء في مرحلة التجميع.
بالإضافة إلى ذلك، تبدأ جوجل تجربة لاختبار التعطيل المحتمل للمواقع بعد وصول المتصفح إلى إصدار يتكون من ثلاثة أرقام بدلاً من رقمين. على وجه الخصوص، في الإصدارات التجريبية من Chrome 96، ظهر الإعداد "chrome://flags#force-major-version-to-100"، عند تحديده في رأس وكيل المستخدم، الإصدار 100 (Chrome/100.0.4650.4) يبدأ عرضها. وفي شهر أغسطس، تم إجراء تجربة مماثلة في متصفح فايرفوكس، والتي كشفت عن مشاكل في معالجة الإصدارات المكونة من ثلاثة أرقام في بعض المواقع.
المصدر: opennet.ru