كان كروم 76 ثغرة في تنفيذ FileSystem API تسمح لك بتحديد استخدام وضع التصفح المتخفي من خلال تطبيق ويب. بدءًا من Chrome 76، بدلاً من حظر الوصول إلى FileSystem API، والذي تم استخدامه كعلامة على نشاط وضع التصفح المتخفي، لم يعد المتصفح يقيد FileSystem API، ولكنه ينظف التغييرات التي تم إجراؤها بعد الجلسة. كما اتضح، التنفيذ الجديد العيوب التي تجعل من الممكن تحديد نشاط وضع التصفح المتخفي كما كان من قبل.
جوهر المشكلة هو أن الجلسة مع FileSystem API في وضع التصفح المتخفي مؤقتة، ولا يتم حفظ البيانات على القرص ويتم الاحتفاظ بها في ذاكرة الوصول العشوائي (RAM). على التوالى، وقت حفظ البيانات عبر FileSystem API والانحرافات التي تنشأ (عند الحفظ في ذاكرة الوصول العشوائي، يتم تسجيل الخصائص الثابتة، بينما عند الكتابة على القرص، يتغير التأخير) يمكنك الحكم بثقة على ما إذا كان يتم عرض الصفحة في وضع التصفح المتخفي أم لا . عيب هذه الطريقة هو عملية قياس الانحرافات الطويلة إلى حد ما والتي يمكن أن تستمر لمدة دقيقة تقريبًا ().
وفي الوقت نفسه، هناك شيء آخر لم يتم إصلاحه في Chrome 76 ، والذي يسمح لك بالحكم على نشاط وضع التصفح المتخفي بناءً على تقييم القيود الموضوعة عبر واجهة برمجة التطبيقات . بالنسبة للتخزين المؤقت المستخدم في وضع التصفح المتخفي، يتم تعيين حدود مختلفة عن التخزين الكامل على القرص.
دعنا نذكرك أن المواقع التي تعمل على نموذج توفير الوصول الكامل عبر الاشتراك المدفوع (paywall) تهتم بتعريف وضع التصفح المتخفي. لجذب جمهور جديد، توفر هذه المواقع للمستخدمين الجدد إمكانية الوصول التجريبي الكامل لبعض الوقت، والذي يتم استخدامه بشكل نشط لتجاوز نظام حظر الاشتراك غير المدفوع. أسهل طريقة للوصول إلى المحتوى المدفوع في مثل هذه الأنظمة هي استخدام وضع التصفح المتخفي، حيث يعتقد الموقع أن المستخدم قد فتح الصفحة لأول مرة. لم يكن الناشرون راضين عن هذا السلوك، لذلك استخدموا بشكل فعال ثغرة مرتبطة بواجهة برمجة التطبيقات FileSystem API لفرض متطلب لتعطيل وضع التصفح المتخفي لمواصلة التصفح.
المصدر: opennet.ru