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...
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 firstname.lastname@example.org (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.