This is based on speculation and guesswork ... but this is what I think they were doing with their original iTether application:
On the client (the Mac) they have a IOKit ethernet driver that shows up in Network Settings. This becomes your default route (after some fake DHCP magic) and then captures packets and relays them to their application that runs in userland.
Their userland application contains a lightweight TCP/IP stack that interprets those packets. (For example http://www.sics.se/~adam/lwip/)
The lightweight TCP/IP stack contains unimplemented callbacks for opening/closing sending/receiving data. In this case those callbacks are implemented as a higher level network protocol.
That 'wrapped' TCP/IP protocol is then relayed to the iPhone via the usbmux protocol. This allows you to map a TCP/IP service on the device to a local port on the Mac. (I happen to have written a nice usbmux proxy three years ago)
So now the wrapped TCP/IP is arriving at the iPhone, in the form of higher level 'network stack commands'. The iPhone app now simply has to interpret these commands and translate them into real socket open/close read/write commands.
At this point packets are flowing through a fake Ethernet device driver to a secondary TCP/IP stack, over a USB cable to an iOS app which will do actual socket calls and talk to the real network.
Soooo, my guess is that for this new app they use basically the same setup except that the iOS app is gone and replaced with a simple web page with web sockets that point to both that fake TCP/IP stack on the mac and to a hosted proxy service on their end. Relaying data back and forth.
Maybe it is just my warped perspective, but when I looked at the technology this all came to mind immediately, but I just as immediately dismissed it because of the "hosted proxy service": the fee was seemingly "too low".
So, I feel like you've left out the key non-obvious part: it turns out that even if you do the brain-dead un-optimized "let's use Amazon EC2" for your proxies, $30/yr at $0.05c/GB (down: up is free) buys 50GB/mo.
Given that the user is then going to be filing this data over their 3G connections, 50GB/mo is (based on reports of users tethering that complain about rate limiting and caps) at the very high-end of usage.
So, with that aside, the rest of this actually boils down to: "the webpage just makes two outgoing websocket connections; one to a proxy, and the other to an app on the PC, itself providing a custom network driver".
However, for this particular service, I think that you could get away with much less by leveraging existing work: modify an OpenVPN client so that it has an additional listen socket; then, use a websockets-based relay to link the OpenVPN client's listen socket and your OpenVPN servers.
A nice thing about this setup is that the webpage with the websockets relay can be dynamically generated and point to any server of your choice for quick load-balancing; it would also make it difficult for carriers to block any single server. The biggest problem would be scaling, since OpenVPN might load a server with just hundreds of active clients (http://forums.openvpn.net/topic9148.html), in which case a custom solution might be better...
Regardless of how they did it, very clever workaround!
On the client (the Mac) they have a IOKit ethernet driver that shows up in Network Settings. This becomes your default route (after some fake DHCP magic) and then captures packets and relays them to their application that runs in userland.
Their userland application contains a lightweight TCP/IP stack that interprets those packets. (For example http://www.sics.se/~adam/lwip/)
The lightweight TCP/IP stack contains unimplemented callbacks for opening/closing sending/receiving data. In this case those callbacks are implemented as a higher level network protocol.
That 'wrapped' TCP/IP protocol is then relayed to the iPhone via the usbmux protocol. This allows you to map a TCP/IP service on the device to a local port on the Mac. (I happen to have written a nice usbmux proxy three years ago)
So now the wrapped TCP/IP is arriving at the iPhone, in the form of higher level 'network stack commands'. The iPhone app now simply has to interpret these commands and translate them into real socket open/close read/write commands.
At this point packets are flowing through a fake Ethernet device driver to a secondary TCP/IP stack, over a USB cable to an iOS app which will do actual socket calls and talk to the real network.
Soooo, my guess is that for this new app they use basically the same setup except that the iOS app is gone and replaced with a simple web page with web sockets that point to both that fake TCP/IP stack on the mac and to a hosted proxy service on their end. Relaying data back and forth.
Crazy hack. Amazing it works :-)