One of these days, the network providers are going to stop putting arbitrary labels on their data, as though "voice", "text" and "data" are not all travelling through the same towers and pipes.
These three activities have different QoS constraints: "voice" data is real time, lossy, and therefore has hardware assisted compression and routing; text messages and data are non-lossy, but have drastically different timing and retry constraints. So, even if they "traveled through the same towers and pipes" (they don't, a detail more expanded on by mdasen in his comment), it wouldn't make sense to charge the same for them as they have different cost requirements (although it might be somewhat more equal than it is now; in particular, text messages, which occupy valuable and limited control channel space, would likely become cheaper).
A) "So it's UDP vs TCP" <- no... you should read up on "QoS"
B) "why can't" <- I did not claim they cannot... I stated that they don't (they don't even use the same frequencies in the air), and that even if they did, you wouldn't charge the same due to the QoS differences.
Text messages are an interesting one. Essentially, they cost nothing to the carrier in that they get transmitted as part of the control channel. However, there is a cost to supporting a phone idling on a network. The control channel has to be in communication with it using up bandwidth. So, the SMS gets put in with the control channel instructions and so its marginal cost is 0, but there's still a cost. Beyond that, your carrier has to pay a termination fee to the receiving carrier when you send a text message to them and that is a cost. So, when you send a text message off-network, there is a cost to your carrier.
Voice similarly travels a different path. In CDMA systems, the voice channel and data channel are physically separate. Even with UMTS where the voice and data traffic travels over the same channel, there have been significant advancements for data transmission (HSPA, HSPA+) that allow for greater efficiency.
Even with VoIP, a real distinction can be made. Like texting, the carrier of the receiving party charges a termination fee to the carrier of the calling party. So, if you're on Verizon and call a user on Sprint, Sprint charges Verizon to connect the call (http://en.wikipedia.org/wiki/Termination_rates). That means that while VoIP would use network resources in the same way as data, the carrier would face a higher cost because of the termination rate. This is also why many free VoIP services won't let you call those free conference call services (http://bits.blogs.nytimes.com/2009/09/25/att-says-google-voi...). They're usually set up with a carrier who charges an absurd termination rate that pays for the service.
While they are travelling through the same towers, they're taking different paths and those different paths do have different costs. Part of it is regulatory: termination fees are meaningful costs to carriers even if one considers them artificial. Part of it is the current time: in 3-5 years, we'll probably be on VoIP. Part of it is that data transmission (wired or wireless) has low marginal costs, but decent fixed costs: it doesn't cost the carrier much to support you as a marginal user, but they have put tens of billions into their network even if your phone just idles on it. Right now, wireless is priced in a "consumer" way. We don't pay for what we use, but rather some awkward approximation based on what they think consumers will accept charges for. This is in contrast to, say, utilities which usually have a fixed charge for being on the network (to cover fixed costs) and then a usage rate (which covers marginal costs).
I don't really have a conclusion. Carriers are trying to make more money off you in a way that's objectionable, but they aren't the same. I won't defend the pricing, but I want to point out the difference.
At least as far as CDMA and WCDMA go, control signalling is shared for all mobiles camped on a cell. In CDMA, while a mobile is just camping there's not a lot of traffic going between the cell and the mobile on the access and reverse access channel. The mobile registers as per the registration settings, and the idles its radio until it is paged by the cell, it originates a call, or the registration settings require it to register again. When idle, there is no signalling going back and forth on the access channel, so that bandwidth can be allocated for other things.
I'm not at all familiar with GSM, so I can't say how it works. I expect it's similar, though.
The labour theory of value is not correct. People view talking, texting and internet as different, and hence businesses will charge different for them.
Cell network providers have only recently been dealing with this problem. Landline and Cable providers have been reselling the same pipe through "voice", "data" and "tv" channels for a lot longer, and they continue to get away with it.
Carriers will not voluntarily give up this incremental revenue. I live in Boston, when my choice of cable carrier are Comcast and errr... ummm.. Comcast.
Until there are more competing vendors, I think this transition away from arbitrary labels to one single dumb pipe will be much slower that we all hope.
Well if you look at it, unless you use "text" for "surfing" like in this app, it actually does not cost much to the providers. You can not type all day, can you?
So by "unlimited" text all they are saying is that you will tire yourself texting say about X SMS and thats it per day.
1000 SMS * 160 chars * 2 bytes each (arbitrary) = 320000 bytes. Thats just 320KB. Thats cheap isn't it? Can you type more than that per day?
I've been trying to access the voice settings to modem-dial for a while, but I didn't think to (ab)use SMS this way.
Why T-Mobile only, though? In theory, you should be able to use this to talk to any SMS gateway, but you're going to end up paying on the gateway side ;(
Of the four major US providers, T-Mobile and Verizon are the only ones with MMS gateways (I use MMS to send the responses) that don't require a sign in by a customer (I only have T-Mobile myself). I tested Verizon's MMS gateway with my friend who has Verizon cell service, but it didn't seem to work for some reason.
Do you use compression at all or is it straight uncompressed HTTP via SMS? Or something else entirely? This is wonderful for it's creative (mis)use of texting...
The requests (which are just URLs, and any postdata/cookies if applicable) are sent to my server via SMS.
The responses are sent back to the phone via MMS, in up to 5 (I think?) segments. I download the webpage along with all resources (stylesheets, images, etc.) and put everything in a zip file. I encode the zip file as a PNG (each RGB pixel is 3 bytes of the zip file) and send the PNG in the MMS.
It doesn't have a "don't send passwords" warning. I should definitely add some kind of warning/disclaimer page that pops up when you boot the app.
I display a warning when the user tries to navigate to an HTTPS URL that messages sent to/from Smozzy aren't encrypted and it's not recommended that you proceed. I had a general idea for an encryption scheme (hardcode Smozzy's certificate's public key into the application and use it to encrypt a randomly generated string with each request and then send that encrypted string with the request and use the unencrypted string as a symmetric key to encrypt the rest of the request/response), but I was kind of too lazy to implement it for the initial release.
What User-Agent string are you using? It's a clever hack, but I can't allow my users to access sensitive information via your proxy. It sounds like you might be changing or adding hosts as you gain users, so blocking based on User-Agent will be a good start (unless, of course, you choose to use your powers for evil, in which case I'll have to resort to my own clever devices).
The user-agent is somewhat configurable within the application. You can currently choose between 4 options: Nexus S, iPhone 4, Windows 7 Chrome, or None (no user agent string sent). I didn't want to change the actual strings from what is used on these devices, because I wasn't sure if sites would still recognize the string as corresponding to a mobile device (in the cases of the Nexus S and iPhone 4 options) if I altered it. Maybe this wasn't the best decision but I wasn't intentionally trying to "use my powers for evil". If anyone can think of an alternative let me know.
You are obviously welcome to block my domain/IP (not that I could stop you). I don't currently plan to expand beyond a single host. Even in the midst of all this coverage my single VPS seems to be working fine. Sorry in advance if I cause problems for you or any other admins...
You could try this http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
Although, it would depend on finding a pre-existing implementation (remember it is a bad idea to implement your own crypto). Is there are trust-worthy source of random characters available?
Well, Diffie-Hellman wouldn't work very well for this since any conversation between my server and the client would take a long time, unless I'm misunderstanding what you're suggesting.
The motivation behind the scheme I came up with is that it could be done with no pre-communication, hence why my RSA public key would be hardcoded into the client.
Any chance we can get it to work with things like Texty or DeskSMS? It seems that these apps grab the MMS messages and the app never receives the page, I think.
One of the few truly interesting articles on Smashing Magazine about optimizing pngs for their filters. It shows that yes, the filters are really a huge part of how pngs get compressed:
No, I wouldn't say that. Those filters make a huge difference to the compression ratio!
The png optimizers you see (optipng, pngcrush, etc)? What they do is carefully pick the optimum filters to get the best file size. So I'd say those filters were the most important part of the compression.
You are correct. I almost qualified the statement as such, but figured "pretty much" was good enough to get my point across in a hurry. My point being that zlib compressed 24-bit RGB values in a PNG is normal. It's a different approach than lossy DCT quantization used in JPEG.
Beautiful and really impressive use of technology. There are times when I'm outside the data network range of T-Mobile, I would make use of this. The app crashed while attempting to receive my first request, does Google send you the crash info when I submit that through the Android reporting system?
The recipient pays if they don't have a messaging plan. You can send an MMS to a US T-Mobile customer by emailing 1115557777@tmomail.net (if their phone number were (111) 555-7777), so that's how I do that.
I don't know, all the carriers over here have a way to send a picture to a phone using an email address. It would be very nearly impossible to block his app: They'd probably have to block individual users for receiving too many emails. Not an attractive option I wouldn't think.
In the 90s they had services that would send you HTTP pages and FTP files via email, for the poor schmocks that had email (e.g. via UUCP) but no FTP or WWW.
You'll be surprised about all the boxes that have been erected for people to think in, as soon as you have discovered the world outside the particular box you've grown up in.
Now, if only people at US T-Mobile saw your app the way I see it - an alternative way of accessing and browsing the web in cases of emergency - not only would you not get shut down, but you'd be given extra resources to develop this further, public praise on creative use of their services and so on.
Of course, if I was Verizon - whose service you say did not work - I wouldn't wait for T-Mobile to get their hands on you first. I'd contact you immediately and I would make sure Verizon's network worked like a charm.
There's ton of completely free PR to be gained here.
However, unfortunately I don't think emergency use when data services aren't up is a legit use case, since webpages are sent from my server to your phone via MMS and I think MMSes are downloaded via a data connection.
I hope it doesn't get shut down TOO fast. I think it has a chance since the userbase will probably be very small, since the number of people who have Android phones without a data plan with US T-Mobile is probably on the order of thousands...
PPK came up with JSON over SMS, which would be a great way for people to use apps with phones (or in countries) that don't support data (including MMS). I guess this is a much bigger problem in developing countries. You can see his slides about this here: http://www.quirksmode.org/blog/archives/2010/10/fronttrends_...
You should make an entertaining mini-game to play every time the page is loading. Since you can consistently count on long load times, make the best of it :)
I saw this when I was googling around to see if anyone had already done this, but I was kind of confused by what exactly it is. I don't think it's the same thing.
It is the same thing. I created a similar tool for use on s60 (symbian) on several carriers in africa. Sitonmobile "packages" up the interactions with a web server into a series of compressed images and delivers it via mms where it can be replayed. It is obviously less interactive but works fairly well for web 1.0 content.
No, it is the same thing. Data is encoded into a static image format only in order to be transported by mms. The difference being that my system and hp's system packaged up a static route through the site so a large amount of ondemand processing was not necessary. It appears this is being done entirely dynamically per request which is an improvement but my experience tells me is not scalable.
T-Mobile's terms (and I would presume other carriers) already say they can cut your unlimited text off if you're using it as some sort of automated gateway. This is meant to keep you from using your cheap text plan as a commercial SMS service (ex: Twitter), they could cut this off as well.
I know a way to use another mobile carrier's data network without paying for any service at all. I thought about making a mobile app to exploit it, but I know they'd probably just close the hole in a couple weeks. It would make a good first attempt at an Android app, though...
I remember getting an Ericsson (A2618?) phone in around 2000 that was advertised as a WAP phone and being very disappointed that it only supported WAP over SMS (UK networks didn't allow that - I think the closest network with support was in Greece).
This is a cool idea, but it sounds like something that will be shut down pretty quickly. If not directly, then by carriers who decide that your unlimited texting plan actually does have a limit, kind of like your "unlimited" data plan.
I am wondering how expensive this would be for a pre-paid plan as a last resort to google information or fetch some mobile sites. I know it is 10c to send SMS and 25c to receive MMS, so can we assume that it would cost a minimum of 35c per each request? If the browser requests more resources when the JS is executed, would it automatically result in more requests to be sent? Can this be somehow controlled? I have unlimited data, so don't need this, but the wife uses a prepaid plan and T-Mobile has no viable data options, so would like to give this option in case of "emergency".
Cool hack! Along the same (disturbed) lines, I wonder if it would be possible to do tcp/ip over SMS using a tun or tap type driver? i.e. take the packet, encode, break into parts, SMS to a remote gateway, undo the packing, reassemble and send it on it's way. Sort of like RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers" but using SMS. Probably slower than pigeons though :-)
Unless it reformatted the page, returning only the textual content. With the maximum size of an MMS being around 100kb (depends on the operator), this is a lot of text.
You could fetch a number of pages at once and read the response even on a feature phone. This can also be combined with a web interface to bundle pages or feeds together and associate them with a shortcode.
Interesting thing about that: if you're curious, dig into the SoCs used for this stuff, and you'll see that's really not about "giving access". The voice handling in most smartphones never leaves the SoC, and the OS just communicates with it like you would with a modem: "call XYZ", "hang up", etc, usually with a familiar AT command set.
Useful side-effect: if the OS crashes, your phone call will typically remain alive. (You probably won't be able to hang up without powering off, though, and definitely won't be able to dial another number.) Or, if you have an original iPhone 3G like mine that's sluggish at the best of times, it doesn't affect the phone call. :)
This is very difficult because the carrier can/will apply various signal processing algorithms to voice streams, these will really screw with your modulated data.
Funny thing is, I just transferred 1TB of data from work to home (offsite backup) in just 5 minutes today... via bicycle even! Didn't even think of that until just now. Guess the saying still holds true then!
Although to be fair, doing the backups took considerably more time - a usb external hard disk doesn't copy 1TB that quickly...
That's pretty great- wish I had an android to try it!
I can't help but wonder what kind of speed you actually get through that- would it be sufficient for day-to-day use, or just enough for a few patient page loads now and then?
Not sufficient for day-to-day use, probably between 15 seconds and a minute to get a page. But if you don't have a data plan, it's possibly better than nothing...
How does this work for sites that use Ajax / Javascript that requires server connections? What about streaming audio / video, and how about cross-site stuff? Does all that get passed through SMS as a proxy?
None of those things work right now (and honestly probably never will). This only has very basic HTTP functionality.
One of the most annoying ones is when sites have Javascript redirects, because my server doesn't know how to follow those. So going to "twitter.com" doesn't work because they have a Javascript redirect to HTTPS. :|
I'd be surprised if so, the userbase is probably going to be pretty tiny. It's not really easy to get an Android phone without a data plan (although it's possible), and there's not really any reason to use it otherwise, other than initial curiosity.
That's odd. It might not show up in your Market search if you don't live in the US (I set it to US only since it won't work for anyone else) or if your device doesn't have the required capabilities for the app (telephony and touchscreen). No idea why you wouldn't be able to get to it using the direct link, though.
For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time.
It's definitely not fast, but it's not quite as bad as you might think. While I was testing it, the whole pipeline, from pressing the "go" button to the page being fully rendered could take as little as 15 seconds.
Granted I'm just releasing this now, so if it gets any users at all we'll see how my cheap VPS holds up...
Let me know if you need a hand with hosting (VPS, dedi, etc). Don't worry about cost (no strings attached). Feel free to drop me a line at joe@unixy.net
Cheers
P.S: We've recently deployed a several 24-core SAS nodes so there's plenty of capacity to spare.
>While I was testing it, the whole pipeline, from pressing the "go" button to the page being fully rendered could take as little as 15 seconds.
How is that possible? I thought the whole point of SMS was that it resided in the wasted bytes towers use when they "ping" phones. The reason text messages aren't instant is that these pings aren't sent frequently. I could be way out to lunch on my understanding, but this seems to be a latency killer (not to mention the limitations of packet size).
The responses aren't sent by SMS, but MMS. My understanding is that to download an MMS you essentially get a data connection with your provider that only lets you download MMSes.
The downstream is sent by MMS, which is just a file download over the internet, so it's not bad. Though, when I first saw it I thought he was base-64 encoding entire requests and stuffing them into 160-char text messages, which really would be crazy.
Wrong on two counts, the first being that SMS messages are 160 characters, Twitter is 140, the second being that SMS is only used for sending requests, the real data arrives via MMS.
By default SMS is 160 characters, but only in the default 7 bit encoding. It's 160*7 bits (of content), which is actually 140 chars in 8 bits.
I guess it depends on your type of characters :)
Great hack! I wonder if it's possible to reverse engineer the protocol so an appropriately crafted SMS message will send a goatse page to a friend's Android. :-)
