I know for sure that what you're saying was true around 10 years ago. Once apps like WhatsApp began to gain popularity in some countries, though, I've seen a few examples of carriers allowing for unlimited SMS and switching to focus on charging for data, like what has happened in the US. But off the top of my head, I can't think of a specific example. I don't think that my ideal "target market" would need both cheap SMS and censored internet access; for me, those are two different applications. If your internet access is censored, even just a small amount of information could prove to be very useful. The other application is countries with cheap SMS plans but expensive data plans, which, like you pointed out, has a pretty limited application.
In theory, you could adapt this approach to whatever needs you have. I have heard people suggest implementing IP over SMS, setup as a local VPN. I would say the sky is the limit, but I think with how brittle, unreliable, and slow SMS is, IP over SMS would definitely be out of scope. If you wanted to make a quick jank solution to your problem, this app works with all HTTP GET requests. So, simply host a local webserver on your PC, have your server phone connected to the same Wi-Fi, and provide a text input box that will accept any command and append it to the url with a basic <form> tag. Then the server can generate the output, and send the result back to you.
Those look like interesting options, and they're surely be more reliable than relying on the phone's own SMS capabilities, but I wasn't able to find a public API for any of those services. As far as SMS rate limiting goes, I agree that multiple numbers would be good. Perhaps if there's a demand for it, I can create a feature that switches numbers from the database on the fly as it notices some are hung up.
>FYI most carriers consider Person to Person messaging to be below 1 message per minute and run between 40% inbound to 60% inbound messages.
Yep, I've read into that a little. I wasn't able to find anything explicitly forbidding a service like this in their terms, although there's a lot of legal documents that carriers have so I could have missed it. I read that you should expect about 1 SMS/second on consumer carriers, but it seems like I'm able to get about 2-3 SMS/second in my testing.
I didn't know about carriers having an unlimited SMS threshold... I'll have to look into that, thanks for the heads up!
The server is back up and running - it turns out that CDMA networks continue to be an issue, and the queue of WebViews was being depleted as any WebView that received a malformed string failed. I fixed that, but the string should never have made it all the way to the webview in the first place, so that was also fixed.
Thanks! And yep, my goal was to make it as easy as possible to host a server without any technical knowledge. I haven't looked into the subject extensively, but I believe those services exist(ed) in the form of Opera Mini and UC Browser. IIRC, Opera Mini's Android app still supports this. Sadly, it's not open source, so you have to trust Opera with all your data, and Opera hasn't exactly had the best track record... I doubt UC Browser is any better in that regard. I used both about 10 years ago when they still had J2ME versions of their apps... It was kind of surreal to use Opera Mini's on a touchscreen dumbphone because they had updated their midlet to look very similar to the iOS 7 version, on a much much inferior device! It worked surprisingly well, compressing text and images.
Thanks and yeah, that's another good application of the idea. It's somewhat similar to iodine[1] in that respect. On the ground in the US, this would probably only be useful if you're hiking in a remote area or something like that, due to how cheap data plans are. It might also come in handy if your carrier doesn't charge for SMS when abroad.
Wouldn't that imply that you were an employee at Google sometime between 2002-2004? :P Unless I'm not getting the full picture (I was not old enough to be fully aware of Gmail's existence in 2004)
I'm not very familiar with infosec. How is the author able to obtain this information? Are there 2 identical files, one source and another encrypted?
>They must be encrypted with AES-128-CBC using key=”)1Zorxo^fAhGlh$#” and IV="aoAkfwk+#1.6G{dE”. Only system.ext4 must be converted to sparse image before the encryption.
Hi there,
I know it's a little distasteful to hijack your comment on an unrelated topic but I didn't know any other way to contact you. About 6 months ago, you commented on my post (https://news.ycombinator.com/item?id=30687601) about making an SMS based browser with improvements over coldsauce's Cosmos Browser. I just wanted to let you know that I've basically finished all my major goals with it and released it publicly! (here's that post: https://news.ycombinator.com/item?id=32905496 ). I hope you enjoy it!
Yet again, I really ought to pay more attention to my results! I was looking at the website https://example.com, which does only total 112 bytes. But https://google.com is actually 3.42kb! That means the actual effective speed is 0.76 kilobytes/second, or about 6 kilobits/sec. A lot faster than I expected!
Thanks! Another user asked a similar question, so I tested loading a simple(r) website like Google. The stripped HTML totaled to 3.42kb, which took 4.5 seconds to transmit. That totals out to 0.76 kilobytes/second of raw transfer speed. This might be lower or higher than the average, but it's a good rough estimate that something like dial-up speeds aren't exactly feasible. This is definitely promising as an alternative when this is the only option available!
Thanks for the reply!
I have considered this idea as a potential solution, which would overcome some of the hurdles of Android's SMS limitations. However, I think the real bottleneck for sending SMS would inevitably be the carriers. Though once I can get some more hardware on my hands, I'd love to try this idea out to see how feasible it might be. In terms of hardware requirements, it would still be a much lower barrier to entry to create a server app that houses the cellular modem and internet abilities into one single package, since no extra hardware cost would be required for small scale operations. But for larger operations, this is definitely the endgame assuming carrier restrictions allow throughput to be faster than achievable with Android.
Just realized I had a brain fart, there's no way that those kind of speeds would be possible! I meant to say 25 bytes per second. Very slow compared to any mobile network, but better than not having any internet access at all.
Thanks for the praise, I know it's not a super huge scale project but it was a good challenge to develop. As far as speed goes, I'm not exactly sure. I know that Twilio's toll free numbers send about 5 SMS messages a second, so once many users use the app at once it would slow down significantly. One thing I'm working on is decentralizing the app so that a Server Android app could be run on a phone that has an internet connection, using that phone's phone number as a way to send pages. About speed, I just ran a test and checked google.com's file size (it's 112 bytes) and timed the page request, upon the first text arriving it only took 4.5 seconds to load. That's a staggering 40kbps! Pretty impressive as a best case scenario, but a bunch of factors will probably make the average a bit lower.
Hello HN,
I've been working on this project for a little under a year now as a college student. I was inspired by the user coldsauce who also created a similar project back in 2014. It turns out this was harder than I anticipated because of the many facets of dealing with SMS - for example, sending over most Greek characters completely garbles the message over Twilio!
The final product (although still in early beta stage) allows most websites (except many sites using Cloudflare) to be viewed in their HTML form without any internet data being transmitted to or from your phone!
I have a couple hundred dollars of Twilio credits in my server right now, so hopefully that will last :)
Good point. I was looking into a way to maximize efficiency on Android without low-level access (no root necessary), so I'm pretty much limited to the charset that I can receive from the Android APIs for encoding binary data into (36864 chars). I was wondering if even the limited character set offered by an Android SMS receiver would still be magnitudes more efficient than the standard GSM-7 character set for encoding binary data, even though the amount of characters is less for each SMS. I'm having a hard time understanding if I'm oversimplifying things by just looking at the ratios 160/128 to 36864/70, in which case I would assume there would be huge benefits to encode data with UCS-2 instead? I haven't the slightest idea in how to accomplish that, maybe iconv would be useful as you mentioned?
That is something interesting to consider though, dedicated hardware could easily take advantage of UCS-2 and encode binary PDUs to the point where you could achieve a somewhat respectable speed for TCP over SMS. Though by that point, I would assume SMS throttling would be a much larger concern so any benefits are mostly theoretical.
Could you elaborate on why UCS-2 is so wasteful? I think that makes sense on the surface level, but if you encoded a message using all the characters available in the BMP that UCS-2 provides then each character has tens of thousands of options rather than <125 with GSM-7. Considering the difference is a little less than half (70 chars per message vs 160), with the right encoding, shouldn't UCS-2 be much more efficient? Or is it not possible to encode data like that?
I appreciate the comment - at first I wasn't sure if it was too ambitious, but once I realized that Android has libraries for parsing HTML and a documented way to send and receive texts, it was more manageable. It was also nice that ColdSauce had created something that I could use as a reference so I wasn't going in blind. I definitely plan on putting up a repo, probably within the next couple weeks. Going into this project I realized there's a lot more potential and the open source community would be beneficial to help expand the scope of this project!
This is crazy that I stumbled upon this post, I just learned about HackerNews today and saw this on the front page! I've been working on making a sort of revival project of Cosmos browser for a couple months now using a custom encoding and better compression. With the GSM 03.38 spec, I found there are 125 usable characters that I could use as a custom base, but I found out that for some reason the 0x10 column of the character set is mostly non-functional using any SMS API like Twilio. The characters from row 0x00 to 0x0A just show up as "?" instead besides the underscore. I contacted support for multiple API providers (Twilio and Plivo) and found that this is an issue on the operator level, which is quite surprising. I doubt this will ever be fixed because the problem runs so deep. This limits the usable characters to 115, which still has surprisingly good improvements in encoding efficiency compared to base64. I also used the (relatively) new Google brotli compression algorithm which allows me to compress even more efficiently. I'm still finishing a proof of concept so I don't have a GitHub repo up yet but I will soon (I'm a first-year CS student so I need to make my code somewhat presentable before it draws the internet's scrutiny, haha). Right now the server uses Python and the client app began as a fork of Cosmos browser. It turns out that getting code from the KitKat era to work on Android 11 isn't the best solution so I'm looking into rewriting the app. Regardless, thank you so much for your work! I'm super excited to finish the proof of concept and I hope to be able to implement the peer-to-peer system you briefly mentioned in the repo by having a "server" option you could turn on in the app that leverages a user's phone number and internet connectivity to allow other users to connect to that number.
Edit: I also want to add that I've looked into UCS-2 encoding (here: https://www.twilio.com/docs/glossary/what-is-ucs-2-character... ) but I'm not sure if the decrease in characters per message (only 70 instead of 160) is worth the greater amount of characters (theoretically 36,864 but probably includes many non-usable characters). It would also require a more complicated encoding algorithm, and I'm not sure how well supported this is by carriers internationally.