Recientemente Google unveiled has begun to implement a new API "Raw Sockets" in Chrome qwhich allows web applications to establish connections direct network networks using the protocols TCP and UDP.
It should be remembered that in 2015, the W3C consortium already tried to standardize the "TCP and UDP Socket" API, but the members of the working group did not reach a consensus and the development of this API was stopped.
However Google is back on track before the need to add a new API and is due to the provision of interoperability with devices network using proprietary protocols that run over TCP and UDP and do not support communication over HTTPS or WebSockets.
It should be noted that the API Raw Sockets will complement the WebUSB, WebMIDI and WebBluetooth APIs low-level already available in the browser, allowing interaction with local devices.
To exclude a negative impact on security, the Raw Sockets API will only allow network calls initiated with the consent of the user and limited to the list of hosts allowed by the user.
The user will have to explicitly confirm the first connection attempt for the new host. With the help of a special flag, the user will be able to disable the output of repeated requests for confirmation of the operation on repeated connections to the same host.
To avoid DDoS attacks, the intensity of the requests through Raw Sockets will be limited and the sending of requests will only be possible after the user interacts with the page. The UDP packets received from hosts not approved by the user will be ignored and will not reach the web application.
The initial implementation does not provide for the creation of listening sockets, but in the future it is possible to provide calls to accept incoming connections from localhost or a list of known hosts.
It also mentions the need to protect against DNS rebinding attacks (an attacker can change the IP address of a user-approved domain name at the DNS level and gain access to other hosts).
It is planned to block access to the domains resolved in 127.0.0.0/8 and the intranet from the network (it is proposed to allow calls to localhost only if the IP address is explicitly entered in the confirmation form).
Among the risks that may arise when the new API is implemented, it is noted that it may be rejected by manufacturers of other browsers, which could lead to compatibility problems.
The developers of the Mozilla Gecko and WebKit engines have not yet resolved their position on a possible implementation of the Raw Sockets API, but Mozilla has previously offered a similar API for the Firefox OS (B2G) project.
If approved in the first stage, the Raw Sockets API is planned to be activated on Chrome OS and only then offered to Chrome users on other systems.
Web developers have commented favorably on the new API and have come up with many new ideas for use in areas where APIs XMLHttpRequest, WebSocket and WebRTC are not enough (from creating browser clients for SSH, RDP, IMAP, SMTP, IRC and printing protocols to developing distributed P2P systems with DHT (Distributed Hash Table), IPFS support and interaction with device-specific protocols IoT).
Moreover, it is also worth mentioning that the register APNIC responsible for the distribution of IP addresses in the Asia-Pacific region has published the results of a traffic distribution analysis on one of the DNS servers root-servers.net.
In which 45,80% of the requests to the root server were due to checks made by browsers based on the Chromium engine. Therefore, almost half of the resources of root DNS servers they are spent performing Chromium diagnostic checks, rather than processing DNS server queries when determining root zones.
Since Chrome accounts for 70% of the web browser market, this diagnostic activity generates around 60 billion requests per day.
Diagnostic checks are used in Chromium to determine if service providers use service providers that redirect requests for non-existent names to their controllers.
Some providers implement such systems to direct traffic to domain names entered with an error; as a rule, pages are displayed with an error warning, a list of probably correct names, and advertisements for non-existent domains.