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!
Ok so I went ahead and bought the service. Here's what I found out:
You'll have to keep the tether client application running on your Mac or PC. So not gonna work for wifi-only iPads. Then you will need to keep the html5 webpage open in order to receive data. They instruct you to set iPhone's screen lock to "never" so it doesn't automatically shuts the web page down in 1 minute or so. So I imagine you can't take phone calls when tethering as the webpage will go offline.
Pricing wise, the first year costs $15 and will be $30 from second year on. They set my paypal up for recurring payment.
Performance wise it's pretty fast on my iPhone 4. Setting up took about 2~3 min, very easy to do. The html5 app needs to connect to both the tether website and the client computer. Took me a few tries to connect to both but once they are connected the speed is pretty comparable to tetherme in jailbroken iPhones.
Excuse my ignorance of Apple products but how can tethering work on a device without a internet connection ? You want to go trough a iPad proxy to get to a WiFi connection ? Why not just connect to WiFi with the PC ?
Interesting that iOS shuts down the connection when the browser is closed or the phone locked. Is is the same with SocketIO? On Android the connection remains open as long as the browser has the tab open.
If that were the case they could easily market a "lite" version that required a personal proxy (at half the cost?). Then to build off that, a corporate version for ~$200*(size) that could be used for your employees using your company proxy. I wonder if they could do mac auth or allow ldap calls for user verification. I could even see this as going so far as a lightweight VPN (if possible).
What's to stop the carriers from simply blocking (or throttling) your proxy servers? Or conversely, simply detecting which customers connect to your proxy servers and automatically charging them for tethering (as they've already done in other cases).
The way they do it is elegant, and could be used in many other places than just the iPhone. All you need is a browser that supports websockets.
I'm not really aware of that stuff, but I'm a bit curious. Do websockets really work over mobile networks (which are, at least in my experience, transparent proxied, and where anything outside of HTTP-on-port-80/HTTPS-on-port-443 is blacklisted into oblivion) ?
My experience is the exact opposite: all networks I've used in the US (Sprint, Verizon, AT&T, and T-Mobile; in essence, all of the major ones) and the few I've used in the UK (while roaming) have all had sufficiently few outgoing ports blocked that I've never run into one (and I use my iPhone as if it were a computer ;P). That said, WebSockets is just an upgrade extension to HTTP, so it is going to go over 80/443 anyway.
Non-web stuff works fine on the mobile networks I've tried it on. I occasionally ssh from my phone directly to my home computer or server, and I've never had a problem with it. Skype works fine over cell data, as do various instant messaging clients.
Even if that weren't true, websockets was designed to look a whole lot like HTTP precisely so that it could work with existing proxies and firewalls.
I was able to get the original before it was pulled from the App Store. it worked well, glad to see they found a work around. I expect some type of backlash from AT&T/Verizon/Sprint However, I hope they make enough to afford the lawyers.
Do US carriers really still restrict tethering? That's really a shame, because the iPhone's built in tethering support is very good, and extremely elegant compared to apps and methods like this one...
I found the exact same thing, especially since they (finally) implemented the Access Point "tethering", it drains more battery but is incredibly convenient and simple to setup.
Once upon a time, I used the very first iPhone proxy application (NetShare), it was significantly more fiddly than native support. And of course you couldn't use the phone while it proxied, that's not an issue with native support.
Disclaimer (I have not tried the new one) How do you know they store it in clear text? Have you seen inside their database? I mean they could be accepting the password in clear text but maybe they run it though a MD5/Sh1/Salt process before it actually gets to the database.
In the video, the guy shows that, by tethering, he can access Hulu even though he's not in the US. So, yeah, it seems they proxy everything through their servers.
If everything has to go through their servers and then downloaded by the Mac/PC, then it basically defeats the whole purpose of tethering.
The real trick is that they found a way to pipe data from the iPhone to the Mac without going through the internet, all using a good ol' browser web page.
Looks like a great service, unfortunate that they're subject to the HTML5/browser limitations (can't lock, etc).
Is there another way to distribute their native version besides through the app store?
My company use TestFlight (https://testflightapp.com/) for iOS game development. Is there anything similar, but better suited to end-user distribution?
More fundamental than the "do they use websockets" question is "what is the multihoming behavior of iOS?"
Sockets alone are not enough -- you need cooperation from the OS to route connections over both wifi and cell data links in the desired fashion.
In this case we can infer it's two connections made by a script running on a web page: one with the "tethered" machine (over wifi) and one with Tether's proxy server (over cell data). The proxy server works in concert with a client on the tethered machine, and the script just relays data between those two connections.
The interesting thing is that iOS permits a single web page to connect over both network links simultaneously. I'm no expert but that seems like something Apple could, and would, kill with an update.
This is so cool! Like to see that even though they were rejected from the app store they still went ahead and found a way to make their idea a reality.
Too bad Android does not have any visible plans to implement WebSocket (which is now RFC 6455). Perhaps the development of HTML5 apps on Android has lower priority for Google than for Apple, to force the development effort into native, which they can curate and control. This hypothesis is also corroborated by comparing HTML5 performance in Android and in iOS (Android is usually 300-500% slower).
Only on 4.0: it represents less than 1.5% of all Androids now. iOS had Websockets since 4.1, for over 1.5 years. Unless Chrome gets back-ported to Android 2.2 and 2.3 it will take a very long time.
yes, but i was addressing your claim that android has no plan to support websockets. obviously they can't make all the old versions websocket compatible, but they do have a clear path forward to supporting them.
I thought 4.0 was supposed to stop that? iOS 5.1 runs on every iOS device released in the last 3 years. When can we expect all Android devices released in the past 2-3 years running the latest OS?
Google could also stop releasing new versions of Android as code drops. Sony is trying to do the right thing and update a large part of their inventory but their ICS ROMs are currently still in beta because they only got access to ICS source in November.
god dammit, why does everything have to be an apple/android battle? can we not complain about the deficiencies of android without some smug apple fanboys chiming in? yes, apple is better at pushing out software updates than android is. that's not relevant to a discussion on where we can and can't use websockets. now go away.
Just trying to lay the blame where it belongs, on Google and the Android ecosystem. You'd have your websockets if Google did the right thing and enforced updates. Has nothing at all to do with the carriers .
I feel like this is not so hard to do with NodeJS and Web sockets.
Small NodeJS app that serves the client connection webpage and acts as a proxy. Set the proxy locally, When you get requests instead of fetching them ask the socket for the data and headers.
On the client just do an XMLHttpRequest for whatever and shove it back down the web socket to the proxy server. Done, Right? I'll do a little experiment when i have time...
Very cool! Too bad the iphone can't lock, and that the wifi-only iPad can't benefit from this.
On a side note, UI related, when I am on this page: http://tether.com/iphone/ and click "Order Now" at the top right, the modal window opens behind the YouTube video.
Interesting concept... Thinking about it, they are making Safari act as the proxy/gateway. I did not dig into it but are they using web socket for achieving that?
I can see their desktop app, sending the request/proxying to Safari which will in turns act the gateway to the net.
Neat.
I don't understand how this works. It seems like when you're connected to the ad-hoc wifi network, all web requests would go through there. How do they get around this?
I'm assuming they're making use of the fact that the iPhone is multihomed when wifi and cellular connections are both enabled. This means that any outboard traffic from iOS could take two routes, but the ad-hoc wifi network is only advertising routes to IP addresses in a (predetermined) private address space. So when the websockets app talks to a private IP address it choses the wifi route and when it talks to a public IP address it choses the cellular route.
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 :-)