Recientemente Представеният от Google започна да прилага нов API „Raw Sockets“ в Chrome qкоето позволява на уеб приложенията да установяват връзки директни мрежови мрежи, използващи протоколите TCP и UDP.
Трябва да се помни, че през 2015 г. консорциумът W3C вече се опита да стандартизира API "TCP и UDP Socket", но членовете на работната група не постигнаха консенсус и разработването на този API беше спряно.
Pero Google отново е на път преди да се наложи добавяне на нов API и се дължи на осигуряването на оперативна съвместимост с устройства мрежа използване на патентовани протоколи които работят над TCP и UDP и не поддържат комуникация през HTTPS или WebSockets.
Трябва да се отбележи, че API Raw Sockets ще допълват API на WebUSB, WebMIDI и WebBluetooth ниско ниво, вече налично в браузъра, позволяващо взаимодействие с локални устройства.
За да се изключи отрицателно въздействие върху сигурността, API на Raw Sockets ще разреши само мрежови обаждания, инициирани със съгласието на потребителя и се ограничава до списъка с хостове, разрешени от потребителя.
Потребителят ще трябва изрично да потвърди първия опит за свързване за новия домакин. С помощта на специален флаг потребителят ще може да деактивира изхода на повтарящи се заявки за потвърждение на операцията при повтарящи се връзки към същия хост.
За да избегнете DDoS атаки, интензивността на заявките чрез Raw Sockets ще бъде ограничена и изпращането на заявки ще бъде възможно само след като потребителят взаимодейства със страницата. The UDP пакетите, получени от неодобрени от потребителя хостове, ще бъдат игнорирани и няма да достигнат до уеб приложението.
Първоначалното внедряване не предвижда създаването на гнезда за слушане, но в бъдеще е възможно да се осигурят повиквания за приемане на входящи връзки от localhost или списък с известни хостове.
Той също така споменава необходимостта от защита срещу атаки за повторно свързване на DNS (нападателят може да промени IP адреса на одобрено от потребителя име на домейн на ниво DNS и да получи достъп до други хостове).
Планира се блокиране на достъпа до домейните, разрешени в 127.0.0.0/8 и интранет от мрежата (предлага се да се разрешат обаждания до localhost само ако IP адресът е изрично въведен във формуляра за потвърждение).
Сред рисковете, които могат да възникнат при въвеждането на новия API, се отбелязва, че той може да бъде отхвърлен от производителите на други браузъри, което може да доведе до проблеми със съвместимостта.
Разработчиците на двигателите Mozilla Gecko и WebKit все още не са решили позицията си относно евентуално внедряване на API на Raw Sockets, но преди това Mozilla е предлагала подобен API за проекта Firefox OS (B2G).
Ако бъде одобрен на първия етап, API на Raw Sockets се планира да се активира в Chrome OS и едва след това да се предлага на потребители на Chrome в други системи.
Уеб разработчици коментираха положително новия API и са измислили много нови идеи за използване в области, където API XMLHttpRequest, WebSocket и WebRTC не са достатъчни (от създаване на клиенти на браузъра за SSH, RDP, IMAP, SMTP, IRC и протоколи за печат до разработване на разпределени P2P системи с DHT (Distributed Hash Table), поддръжка на IPFS и взаимодействие със специфични за устройства протоколи IoT) .
Освен това, също си струва да се спомене това регистъра APNIC отговарящ за разпространението на IP адреси в Азиатско-Тихоокеанския регион публикува резултатите от анализ на разпределението на трафика на един от DNS сървърите root-servers.net.
При което 45,80% от заявките към главния сървър се дължат на проверки направени от браузъри на базата на двигателя на Chromium, Поради това, почти половината от ресурсите на корен DNS сървъри те се изразходват за извършване на диагностични проверки на Chromium, вместо за обработка на заявки за DNS сървър при определяне на коренни зони.
Тъй като Chrome представлява 70% от пазара на уеб браузъри, тази диагностична дейност генерира около 60 милиарда заявки на ден.
Диагностичните проверки се използват в Chromium за да се определи дали доставчиците на услуги използват доставчици на услуги, които пренасочват заявките за несъществуващи имена към техните контролери.
Някои доставчици прилагат такива системи за насочване на трафика към имена на домейни, въведени с грешка; като правило страниците се показват с предупреждение за грешка, списък с вероятно верни имена и реклами за несъществуващи домейни.