Recientemente Google avalikustas uue API rakendamise Chrome'i q toores pistikupesadmis võimaldab veebirakendustel ühendusi luua otse võrguvõrke protokollide abil TCP ja UDP.
Tuleb meeles pidada, et 2015. aastal üritas W3C konsortsium juba standardida "TCP ja UDP Socket" API-t, kuid töörühma liikmed ei jõudnud üksmeelele ja selle API arendamine peatati.
Pero Google on jälle õigel teel enne uue API lisamise vajadust ja see tuleneb seadmetega koostalitlusvõime tagamisest võrku patenteeritud protokolle kasutades mis töötavad üle TCP ja UDP ning ei toeta HTTPS või WebSocketsi kaudu suhtlemist.
Tuleb märkida, et API Toored pesad täiendavad WebUSB, WebMIDI ja WebBluetooth API-sid madal tase on brauseris juba saadaval, võimaldades suhtlemist kohalike seadmetega.
Turvalisuse negatiivse mõju välistamiseks kasutage toorpesade API-d lubab võrgukõnesid ainult kasutaja nõusolekul ja piiratud kasutaja poolt lubatud hostide loendiga.
Kasutaja peab esimese ühenduse katse sõnaselgelt kinnitama uuele peremehele. Spetsiaalse lipu abil saab kasutaja keelata korduvate ühenduste korral sama hostiga toimingu kinnitamise korduvate taotluste väljundi.
DDoS-rünnakute vältimiseks toorpesade kaudu päringute intensiivsus on piiratud ja päringute saatmine on võimalik alles pärast seda, kui kasutaja lehega suhtleb. The Kasutajatelt kinnitamata hostidelt saadud UDP-pakette ignoreeritakse ja need ei jõua veebirakendusse.
Esialgne rakendamine ei näe ette kuulamispesade loomist, kuid tulevikus on võimalik helistada kohalike hostide sissetulevate ühenduste või teadaolevate hostide loendi vastuvõtmiseks.
Samuti mainitakse vajadust kaitsta DNS-i taaskinnitavate rünnakute eest (ründaja saab muuta DNS-tasemel kasutaja poolt heaks kiidetud domeeninime IP-aadressi ja pääseda juurde teistele hostidele).
Plaanis on blokeerida juurdepääs domeenis 127.0.0.0/8 lahendatud domeenidele ja sisevõrku võrgust (tehakse ettepanek lubada kõned kohalikule hostile ainult juhul, kui kinnitusvormi on selgesõnaliselt sisestatud IP-aadress).
Uue API juurutamisel tekkida võivate riskide hulgas märgitakse, et teiste brauserite tootjad võivad selle tagasi lükata, mis võib põhjustada ühilduvusprobleeme.
Mootorite Mozilla Gecko ja WebKit arendajad pole veel oma seisukohta Raw Sockets API võimaliku juurutamise osas lahendanud, kuid Mozilla on varem Firefox OS (B2G) projekti jaoks pakkunud sarnast API-d.
Kui Raw Sockets API kiidetakse heaks esimeses etapis, plaanitakse see aktiveerida Chrome OS-is ja pakkuda seda alles seejärel teiste süsteemide Chrome'i kasutajatele.
Veebiarendajad on uut API-d ja on välja pakkunud palju uusi ideid kasutamiseks piirkondades, kus API-d XMLHttpRequest, WebSocket ja WebRTC pole piisavad (alates brauseriklientide loomisest SSH, RDP, IMAP, SMTP, IRC jaoks ja protokollide printimiseks kuni hajutatud P2P süsteemide arendamiseni koos DHT-ga (Distributed Hash Table), IPFS-i toe ja suhtluse seadmespetsiifiliste protokollidega IoT) .
Lisaks seda tasub ka mainida registrisse APNIC vastutab IP-aadresside levitamise eest Aasia ja Vaikse ookeani piirkonnas avaldas liikluse jaotuse analüüsi tulemused ühes DNS-serveris root-servers.net.
Milles 45,80% taotlustest juurserverisse tulekuks olid kontrollid tehtud brauserite põhjal Chromium mootoril. Seetõttu peaaegu pool root-DNS-serverite ressurssidest need kulutatakse Chromiumi diagnostiliste kontrollide tegemiseks, mitte juurtsoonide määramisel DNS-serveri päringute töötlemiseks.
Kuna Chrome moodustab 70% veebibrauseri turust, genereerib see diagnostiline tegevus päevas umbes 60 miljardit päringut.
Chromiumis kasutatakse diagnostilisi kontrolle teha kindlaks, kas teenusepakkujad kasutavad teenusepakkujaid, kes suunavad olematute nimede taotlused oma kontrolleritele ümber.
Mõned pakkujad rakendavad selliseid süsteeme liikluse suunamiseks veaga sisestatud domeeninimedele; reeglina kuvatakse lehed veahoiatusega, tõenäoliselt õigete nimede loendiga ja olematute domeenide reklaamidega.