مؤخرا كشفت Google عن بدء تنفيذ واجهة برمجة تطبيقات جديدة "مقابس خام" في Chrome qالذي يسمح لتطبيقات الويب بإنشاء اتصالات شبكات الشبكة المباشرة باستخدام البروتوكولات TCP و UDP.
يجب أن نتذكر أنه في عام 2015 ، حاول اتحاد W3C بالفعل توحيد واجهة برمجة التطبيقات "TCP و UDP Socket" ، لكن أعضاء مجموعة العمل لم يتوصلوا إلى إجماع وتم إيقاف تطوير واجهة برمجة التطبيقات هذه.
بيرو جوجل عاد إلى المسار الصحيح قبل الحاجة إلى إضافة واجهة برمجة تطبيقات جديدة ويرجع ذلك إلى توفير إمكانية التشغيل البيني مع الأجهزة شبكة الاتصال باستخدام بروتوكولات الملكية التي تعمل عبر TCP و UDP ولا تدعم الاتصال عبر HTTPS أو WebSockets.
وتجدر الإشارة إلى أن API ستكمل مقابس Raw واجهات برمجة تطبيقات WebUSB و WebMIDI و WebBluetooth المستوى المنخفض متاح بالفعل في المتصفح ، مما يسمح بالتفاعل مع الأجهزة المحلية.
لاستبعاد تأثير سلبي على الأمان ، واجهة برمجة تطبيقات Raw Sockets لن يسمح إلا بمكالمات الشبكة التي تبدأ بموافقة المستخدم وتقتصر على قائمة المضيفين المسموح بها من قبل المستخدم.
سيتعين على المستخدم تأكيد محاولة الاتصال الأولى صراحة للمضيف الجديد. بمساعدة علامة خاصة ، سيتمكن المستخدم من تعطيل إخراج الطلبات المتكررة لتأكيد العملية على الاتصالات المتكررة لنفس المضيف.
لتجنب هجمات DDoS ، ستكون شدة الطلبات من خلال Raw Sockets محدودة ولن يكون إرسال الطلبات ممكنًا إلا بعد تفاعل المستخدم مع الصفحة. ال سيتم تجاهل حزم UDP المستلمة من الأجهزة المضيفة التي لم يوافق عليها المستخدم ولن تصل إلى تطبيق الويب.
لا ينص التطبيق الأولي على إنشاء مآخذ استماعولكن في المستقبل من الممكن توفير مكالمات لقبول الاتصالات الواردة من المضيف المحلي أو قائمة بالمضيفين المعروفين.
يذكر أيضًا الحاجة إلى الحماية من هجمات إعادة ربط DNS (يمكن للمهاجم تغيير عنوان IP لاسم المجال المعتمد من قبل المستخدم على مستوى DNS والوصول إلى مضيفين آخرين).
من المخطط حظر الوصول إلى المجالات التي تم حلها في 127.0.0.0/8 والإنترانت من الشبكة (يُقترح السماح بالمكالمات إلى المضيف المحلي فقط إذا تم إدخال عنوان IP بشكل صريح في نموذج التأكيد).
من بين المخاطر التي قد تنشأ عند تنفيذ واجهة برمجة التطبيقات الجديدة ، يلاحظ أنه قد يتم رفضها من قبل الشركات المصنعة للمتصفحات الأخرى ، مما قد يؤدي إلى مشاكل التوافق.
لم يحسم مطورو محركات Mozilla Gecko و WebKit بعد موقفهم بشأن التنفيذ المحتمل لواجهة برمجة تطبيقات Raw Sockets ، لكن Mozilla عرضت سابقًا واجهة برمجة تطبيقات مماثلة لمشروع Firefox OS (B2G).
إذا تمت الموافقة عليها في المرحلة الأولى ، فمن المخطط تنشيط واجهة Raw Sockets API على نظام التشغيل Chrome ، وعندها فقط يتم تقديمها لمستخدمي Chrome على الأنظمة الأخرى.
مطوري الويب علقوا بشكل إيجابي على API الجديد و لقد توصلوا إلى العديد من الأفكار الجديدة للاستخدام في المناطق التي توجد بها واجهات برمجة التطبيقات XMLHttpRequest و WebSocket و WebRTC ليست كافية (من إنشاء عملاء المستعرضات لبروتوكولات SSH و RDP و IMAP و SMTP و IRC والطباعة لتطوير أنظمة P2P الموزعة باستخدام DHT (جدول التجزئة الموزع) ودعم IPFS والتفاعل مع البروتوكولات الخاصة بالجهاز IoT) .
وعلاوة على ذلك، ومن الجدير بالذكر أن السجل APNIC مسؤول عن توزيع عناوين IP في منطقة آسيا والمحيط الهادئ نشر نتائج تحليل توزيع حركة المرور على أحد خوادم DNS root-servers.net.
فيها 45,80٪ من الطلبات إلى خادم الجذر كان بسبب الشيكات بواسطة متصفحات تعتمد على محرك Chromium. لذلك، ما يقرب من نصف موارد خوادم DNS الجذرية يتم إنفاقهم على إجراء فحوصات تشخيصية لـ Chromium ، بدلاً من معالجة استعلامات خادم DNS عند تحديد مناطق الجذر.
نظرًا لأن Chrome يمثل 70٪ من سوق متصفحات الويب ، فإن نشاط التشخيص هذا ينتج حوالي 60 مليار طلب يوميًا.
تستخدم الفحوصات التشخيصية في Chromium لتحديد ما إذا كان مقدمو الخدمة يستخدمون موفري الخدمة الذين يعيدون توجيه طلبات الأسماء غير الموجودة إلى وحدات التحكم الخاصة بهم.
يقوم بعض المزودين بتطبيق مثل هذه الأنظمة لتوجيه حركة المرور إلى أسماء المجالات التي تم إدخالها مع وجود خطأ ؛ كقاعدة عامة ، يتم عرض الصفحات مع تحذير من الخطأ ، وقائمة بأسماء ربما تكون صحيحة ، وإعلانات لنطاقات غير موجودة.