That's even more horribly wonderful than I expected! I suspect you'd get a 4.0 if you went for a degree in Southern Engineering.

Nice. I hope the app has a "don't send passwords" warning in there ;) Also, how do you (do you?) handle SSL operations, specially POSTs?

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.

That's really cool. I didn't realize you could do a lossless 24-bit palette with PNG.

A PNG is pretty much a zlib compressed bitmap.

That's not true. PNG has some filters that pre-compress the image before sending it to zlib.

I'd say that still falls under the realm of being "pretty much a zlib compressed bitmap", no?

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:

http://www.smashingmagazine.com/2009/07/15/clever-png-optimi...

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.

Haha! Dude, you are an evil genius.

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?

You really can't think outside of the box any more than that.

This is so impressive.

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.

I assume you've seen this: Richard Stallman in 2007: http://lwn.net/Articles/262570/ (HN Discussion: http://news.ycombinator.com/item?id=1378422 )

Who pays for the MMS you send back? You or the recipient? (Or is it free?)

The recipient pays if they don't have a messaging plan. You can send an MMS to a US T-Mobile customer by emailing [email protected] (if their phone number were (111) 555-7777), so that's how I do that.

> so that's how I do that.

Probably not for long!

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.