Tether Launches HTML5-Based iPhone Tethering Solution(macrumors.com)
macrumors.com
Tether Launches HTML5-Based iPhone Tethering Solution
http://www.macrumors.com/2012/03/09/tether-launches-html5-based-iphone-tethering-solution/
63 comments
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".
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".
That's basically the way to make such apps.
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!
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!
Not really but good guess. We didn't make TetherMe. Maybe you mean iTether?
Hey guys. I'm the developer behind this tech.
Glad to see it's got you thinking :). It took a lot of brainstorming and testing/debugging to get this up and running.
Hope you enjoy it!
Glad to see it's got you thinking :). It took a lot of brainstorming and testing/debugging to get this up and running.
Hope you enjoy it!
It did get me and I'm sure a lot of other people thinking. Would you mind answering this Quora question that I set up so I can sleep tonight?
http://www.quora.com/How-does-the-Tether-HTML5-app-work
http://www.quora.com/How-does-the-Tether-HTML5-app-work
I can't really go into much more detail than the first responder did without getting into trouble :)
Let's just say it's magic.
Let's just say it's magic.
If that’s how it works it means that all my data is going through your proxy server. Is that correct? Is the connection encrypted?
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).
Yes we have proxy servers. And yes the connection is encrypted
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).
Any plans for Linux clients?
If anything, simply releasing a "Here's what the client is doing so recreate it however possible..." might suffice.
(edited; previously sounded impolite)
If anything, simply releasing a "Here's what the client is doing so recreate it however possible..." might suffice.
(edited; previously sounded impolite)
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.
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.
>So not gonna work for wifi-only iPads
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 ?
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 ?
You could want to use the iPad as the client. Ie use an iPhone to give internet connection to the iPad.
(I guess that what the GP meant)
Yeah, we almost have this working an know there is a huge demand for it. Still a few technical hurdles to solve though.
Oh I see, that makes sense :)
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.
Wow. Cool hack.
But if you're friends with an iOS developer, you can ask him or her to build an ad-hoc copy of iProxy for your iPhone and it won't cost you anything.
(Or get 100 of your closest iPhone-using friends to pitch in on an iOS developer account)
https://github.com/tcurdt/iProxy/wiki
But if you're friends with an iOS developer, you can ask him or her to build an ad-hoc copy of iProxy for your iPhone and it won't cost you anything.
(Or get 100 of your closest iPhone-using friends to pitch in on an iOS developer account)
https://github.com/tcurdt/iProxy/wiki
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) ?
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.
Same experience here. I use SSH over a wide variety of ports, and never had it blocked by 3G before...
Yes they do. We've tested them on iPhones, BlackBerry browser, and the Aurora browser on Android.
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.
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.
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.
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.
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.
For a company that will be handling all of my web browsing, I would have expected them to not store my password in clear text.
Doesn't inspire confidence :(
Great product idea though!
Doesn't inspire confidence :(
Great product idea though!
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.
I'm assuming you mean the ad-hoc password. I will change this in the next release.
I can assure you that the data is encrypted from the phone to the server and never stored anywhere.
I can assure you that the data is encrypted from the phone to the server and never stored anywhere.
How! That's what I really want to know. Streaming sockets?
Would everything have to go through their servers? I can’t imagine that HTML5 apps on iOS have permission to open enough sockets to avoid that.
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.
Yeah, it looks like they use WebSockets, and the iPhone webpage just pipes data from the Mac/PC app to 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.
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.
The question is how does the data get to the iPhone, and yes, it appears it all goes through their servers.
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?
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.
Really clever hack, though.
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.
Really clever hack, though.
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...
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...
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).
Opera Mobile supports Web Sockets and runs on almost any Android device.
http://caniuse.com/#feat=websockets
http://caniuse.com/#feat=websockets
chrome for android supports websockets.
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.
Except that Mobile Safari still crashes if you have a proxy server enabled and try to open a WebSocket:
https://github.com/LearnBoost/socket.io/issues/193
Pretty annoying.
https://github.com/LearnBoost/socket.io/issues/193
Pretty annoying.
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?
when the carriers and handset manufacturers pull their collective thumbs out of their asses.
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.
http://developer.sonymobile.com/wp/2011/12/07/ice-cream-sand...
http://developer.sonymobile.com/wp/2011/12/07/ice-cream-sand...
Is that what had to happen for Apple to do it? I thought Android was on the same carriers?
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 .
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.
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.
Thanks, I'll get our web dev guy to look into that.
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.
This sounds awesome, but please don't send my password back over email.
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.
http://en.wikipedia.org/wiki/Multihoming
http://en.wikipedia.org/wiki/Multihoming
Why must I sign up in order to find out how much it cost?
That's a good question. We'll change that.
Can we expect any way to tether a Wifi-only iPad or iPod touch to this service in future?
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 :-)