مؤخرا أعلن مطورو Google عن نيتهم في العامين المقبلين لتعليق دعم Chrome تمامًا لملفات تعريف الارتباط للجهات الخارجية تم إنشاؤه عند الوصول إلى مواقع أخرى غير مجال الصفحة الحالية حيث تُستخدم ملفات تعريف الارتباط هذه لتتبع تحركات المستخدم بين المواقع في كود شبكات الإعلان وأدوات الوسائط الاجتماعية وأنظمة تحليل الويب.
هذا هو حركة تسير جنبًا إلى جنب مع المكالمة التي أطلقها مطورو Chromium في منتدياتهم ، لأنهم فعلوا ذلك تنوي إزالة رأس وكيل المستخدم بالإضافة إلى تقييد الوصول إلى خاصية navigator.userAgent في JavaScript.
جميع هذا يرجع إلى مبادرة Privacy Sandbox بهدف الوصول إلى حل وسط بين الحاجة إلى الحفاظ على سرية المستخدم ورغبة الشبكات والمواقع الإعلانية في تتبع تفضيلات الزوار.
بحلول نهاية هذا العام ، في وضع الاختبار في الأصل، من المتوقع تضمين واجهات برمجة تطبيقات إضافية في المتصفح لقياس التحويل والتخصيص من الدعاية دون استخدام ملفات تعريف الارتباط الخاصة بطرف ثالث.
لتحديد فئة الفائدةمن المستخدمين دون تحديد هوية فردية ودون الرجوع إلى تاريخ الزيارات لمواقع محددة ، الشبكات الإعلانية مدعوة لاستخدام Floc APIبالإضافة إلى تقييم نشاط المستخدم بعد التحول إلى الإعلان ، وقياس تحويل واجهة برمجة التطبيقات وفصل المستخدمين دون استخدام المعرفات بين المواقع مع Token API Trust.
نحن نعمل بنشاط عبر النظام البيئي لمنح المتصفحات والناشرين والمطورين والمعلنين الفرصة لتجربة هذه الآليات الجديدة ، واختبار ما إذا كانت تعمل بشكل جيد في مواقف مختلفة ، وتطوير تطبيقات الدعم ، بما في ذلك استهداف الإعلانات والقياس ، ورفض منع الخدمة (DoS) ومكافحة البريد العشوائي / الاحتيال والمصادقة الموحدة.
يتم تنفيذ تطوير المواصفات المتعلقة بعرض الإعلانات المستهدفة دون انتهاك السرية بواسطة مجموعة عمل منفصلة تم إنشاؤها بواسطة منظمة W3C.
حاليا ، في سياق الحماية من نقل ملفات تعريف الارتباط أثناء هجمات CSRF ، يتم استخدام سمة SameSite المحدد في رأس Set-Cookie ، والذي ، اعتبارًا من Chrome 76 ، تم تعيينه على "SameSite = Lax" افتراضيًا ، مما يقيد إرسال ملفات تعريف الارتباط من مواقع الجهات الخارجية ، ولكن يمكن للمواقع إزالة التقييد عن طريق تعيين SameSite = None بشكل صريح عندما ضبط ملف تعريف الارتباط.
سمة SameSite يمكن أن تأخذ قيمتين "صارم" أو "متساهل".
- في الوضع "الصارم" ، لا يتم إرسال ملفات تعريف الارتباط لأي نوع من طلبات المواقع المشتركة.
- أثناء التواجد في الوضع "التراخي" ، يتم تطبيق قيود أخف ولا يتم حظر نقل ملفات تعريف الارتباط إلا للطلبات الثانوية بين المواقع ، مثل طلب صورة أو تنزيل محتوى عبر إطار iframe.
في الإصدار التالي من الكروم 80 (والذي من المقرر في 4 فبراير) سيتم تطبيق قيد أكثر صرامة يحظر معالجة ملفات تعريف الارتباط الخاصة بالجهات الخارجية للطلبات بخلاف HTTPS (مع السمة SameSite = لا شيء ، لا يمكن تعيين ملفات تعريف الارتباط إلا في الوضع الآمن).
وبالإضافة إلى ذلك، يستمر العمل على تنفيذ الأدوات للتعرف والحماية من استخدام التعريف السري وطرق تجاوز التتبع ("بصمات المتصفح").
في Firefox من الإصدار 69 ، يتم افتراضيًا تجاهل ملفات تعريف الارتباط بواسطة جميع أنظمة التتبع التابعة لجهات خارجية.
تعتبر Google هذا المنع مبررًا ، لكنه يتطلب إعدادًا أوليًا لنظام الويب البيئي وتوفير واجهات برمجة تطبيقات بديلة لحل المهام التي تم استخدام ملفات تعريف ارتباط الطرف الثالث لها سابقًا ، دون انتهاك السرية ودون تقويض نماذج تحقيق الدخل للمواقع الممولة من خلال عرض الإعلانات.
استجابةً لحظر ملفات تعريف الارتباط دون توفير بديل ، لم تتوقف شبكات الإعلانات عن التتبع ، بل تحولت فقط إلى استخدام طرق أكثر تعقيدًا استنادًا إلى تعريف المستخدم المخفي (بصمة الإصبع) أو إنشاء نطاقات فرعية منفصلة للمتعقب على مجال الموقع الذي يظهر فيه الإعلان معروض.
مصدر: https://blog.chromium.org