News: 1598057833

Now that web safety has been completely solved, Google's Chromium team has proposed a way to allow web apps to establish direct TCP and UDP network connections, a powerful capability that could complicate web security.

The [1]Raw Sockets API , which may end up being [2]renamed the Direct Sockets API , represents an attempt to give browser apps networking capabilities that aren't possible via data transport options like HTTP, WebSockets and WebRTC. It essentially allows the browser to talk directly to devices and other computers via the network.

Chromium engineer Eric Willigers announced plans to [3]prototype the API on Wednesday. Assuming testing goes well, the intent is to ship the tech for Chrome OS before there's a general Chromium release.

"Many network devices use their own protocols over TCP or UDP, instead of using HTTPS or a WebSockets-compatible server," Willigers explained. "Like WebUSB, WebMIDI and WebBluetooth, this API allows web apps to communicate with local devices and information systems."

Browser plugin technologies like ActiveX, Java applets, and Microsoft Silverlight have provided this sort of connectivity in the past. But these have fallen out of favor, largely due to security problems.

The Raw/Direct Sockets API will allow web apps to communicate over SSH, RDP, and IRC, among other protocols, with printers and industrial devices, and with various legacy systems. It has the potential to enable better web mail clients and apps based on decentralized peer-to-peer routing based on distributed hash tables.

It could also expand the browser attack surface. As Willigers points out in his Raw/Direct Sockets write up, something along these lines was proposed in 2008 but never realized due to the potential for abuse.

The explainer attempts to address possible problems at the outset, citing various risks and proposing potential mitigations. The risks include:

MITM attacks that inject sockets API calls into a web page or hijack plaintext connections.

Web apps making connections or conducting DDoS attacks without the user's knowledge.

Bypassing third parties' CORS policies.

Third party iframes or scripts that initiate connections.

Covert DNS manipulation to expose resources behind a firewall.

Using the API to violate corporate policies.

There are also various ways the API could be used to violate the privacy of Chromium browser users, to the extent such a thing even exists anymore in an environment where websites regularly load dozens of trackers.

Google's software engineers make it sound as if the risks can be managed. In response to a Twitter [4]post by privacy researcher and consultant Lukasz Olejnik that points out possible problems with building advanced networking capabilities into the browser, Google senior staff software engineer Alex Russell [5]said , "Note that this capability is already available to [6]Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use."

Mozilla staff security engineer April King offered a similarly [7]skeptical tweet about the proposed popup interface that browsers would present as a defense against covert connections. The browser would prompt the user to specify the hostname or IP address, with a checkbox to authorized future connections to the host.

I shall definitely be saving this for my good intentions archive. [8]pic.twitter.com/dhKNvF6mR0 — April King 🌀 (@CubicleApril) [9]August 21, 2020

Pressed for further explanation by Google Chrome engineering director Justin Schuh, who proposed the input mechanism as a defense against abuse, King [10]replied , "Have browsers ever had a permission dialogue requiring user text input? I honestly can’t think of many in all of computing, ever."

FYI: Chromium's network probing accounts for about half DNS root server traffic, says APNIC [11]READ MORE

Regardless of how the permission prompt eventually gets implemented, there's at least some [12]support for the idea among web devs.

IT admins "rely on super dodgy, poorly maintained native software that runs at elevated privilege and is often riddled with vulnerabilities," [13]said Schuh. "If we can make this sort of use case work safely on the web, it would be a massive improvement over the status quo."

In response King [14]quipped , "It’s not the super dodgy, poorly maintained native software that I’m worried about. It’s the super dodgy, poorly maintained server software that is now one XSS away from hostile socket connections."

Schuh, undeterred, advised posting any concerns to [15]Issues thread in the APIs GitHub repo. ®

Get our [16]Tech Resources



[1] https://github.com/WICG/raw-sockets

[2] https://github.com/WICG/raw-sockets/pull/13

[3] https://groups.google.com/a/chromium.org/g/blink-dev/c/ARtkaw4e9T4/m/npjeMssPCAAJ

[4] https://twitter.com/lukOlejnik/status/1296471401147305986?s=20

[5] https://twitter.com/slightlylate/status/1296471942573293568?s=20

[6] https://developer.chrome.com/apps/socket

[7] https://twitter.com/CubicleApril/status/1296625841162588162?s=20

[8] https://t.co/dhKNvF6mR0

[9] https://twitter.com/CubicleApril/status/1296625841162588162?ref_src=twsrc%5Etfw

[10] https://twitter.com/CubicleApril/status/1296637714037649413?s=20

[11] https://www.theregister.com/2020/08/21/chromiums_dns_network/

[12] https://discourse.wicg.io/t/filling-the-remaining-gap-between-websocket-webrtc-and-webtranspor/4366/3

[13] https://twitter.com/justinschuh/status/1296817016611848194?s=20

[14] https://twitter.com/CubicleApril/status/1296818570958077952?s=20

[15] https://github.com/WICG/raw-sockets/issues

[16] https://whitepapers.theregister.com/