January 2008 Archives

Chris Josephes

AddThis Social Bookmark Button

Sam wrote a blog post about the cost of SMS messages. I admire the effort, but I’m not in 100% agreement with his conclusion.

I think the goal the author was trying to make is that SMS messages are overpriced, and consumers should be outraged. To support his arguments, he compares a price per byte breakdown between a SMS message, an email message, and a printed document with thousands of characters (whether binary, hexadecimal or base64, I couldn’t tell you). Unfortunately, the comparisons seem a little weak, and a real cost breakdown between these two technologies is not fair.

Let’s take a look at 3 points the author tries to make.

1. What is the value (and the cost) of an SMS message?

A SMS message typically originates from one user’s cell phone and arrives at another user’s cell phone. People use them for quick messages that either don’t need an immediate reply, or do not require the receiver to have 100% of their attention on their cell phone. Everyone has sent one of these at one time or another: “I’ll be late for lunch”, “OMG! TTYL?”, or “I never want to see your cheating face again”.

You don’t need to boot up a PC, and you have a higher expectation that someone will notice the message quicker, because almost everyone carries their cell phone with them. These aspects of SMS are features that carry a dollar value. Twenty cents may seem high per message when the technology cost is almost zero, but technology is not the only expense by a carrier.

First and foremost, people are needed to maintain the service. That includes systems administrators, engineers, and customer support personnel. Those costs need to be in balance with the total number of SMS messages that pass through a network. Every carrier out there has already measured their own cost per SMS message, and that includes transport, personnel costs, and billing costs. If SMS isn’t profitable, people could lose their jobs, or the per message price could go up.

2. Ah, but SMS shouldn’t have any cost, because the infrastructure is already in place, right?

Not exactly.

A per unit SMS charge could mean that you’re actually paying less for your base service. If every customer is expected to send 25 messages a month, they could reduce the base price to be competitive, knowing they’ll recover that cost with the add ons. If you send under 25 messages, the carrier hopes that the emotional teenager down the street will send 50 messages to cover your slack.

Alternatively, a carrier could reduce operating costs by offering unlimited messages for a base price, like $10 for unlimited messages; but that creates the risk that consumers would just forgo SMS altogether.

3. Apples and Oranges (Is email cheaper than SMS?)

The other aspect of this article that confuses me is the comparison between SMS and email. To put this in a better perspective, I’ll make my own argument.

If I were to fly from Minneapolis to Denver, the price of a one way ticket would be $290.23 with a flight time of approximately 2.5 hours. If I were to drive the exact same trip, my gas cost would be $180 (assuming that I can get 350 miles for every full tank of gas), and I would get there within 17 hours.

With either solution, I end up in Denver. Why does the airline in this case feel justified in charging such a higher cost? And if you think about it, that plane is going to Denver anyways, so I should be able to just ride it for free.

My comparison is a fail of epic proportions, because both methods of transportation have different operating costs. Airplanes cost more than cars, automobile gasoline has a tax for maintaining roads, flight attendants need paychecks. In both cases I’m paying different amounts of money, with different service expectations, but getting the exact same result.

The comparison between email and SMS isn’t fair because the author admits that there is no per email message cost. No ISP would ever want to deal with billing per email message, because the tracking of incoming and outgoing messages would only increase the price. You can use your bandwidth for web surfing, email, online games, or anything. SMS messaging does not offer these features.

Next, let’s discuss the idea of sending a single MP3 file (much less 2,560) over the SMS protocol. This is totally unreasonable action due to the size limits of SMS messages. SMS was never designed to transfer files, so why compare a file transfer? Most cell phone offer other methods, such as Bluetooth, or dedicated data networks for sending files. And while I’m at it, email isn’t the best protocol for file transfers either. If I had 2,560 individual emails of 4gb each, I would be looking at one mbox file of 10gb. Managing that mailbox would kill most mail clients, and probably a couple of IMAP servers as well.

Finally, the author is incensed that the person receiving the SMS message may also have to pay a surcharge. Unfortunately, he fails to point out that the recipient of the email message will very likely have an ISP charge as well.

Conclusion

If I’m coming across as harsh, it’s not my intention. This analysis is simply a counterpoint to the claim that text messages are expensive. Yes, they do cost a consumer money, and they probably make a profit for the carriers. I do not think this means SMS messages are bad, or exploitative.

The best way for a consumer to determine the cost of SMS messaging is to see what benefits the service gives you. If they save time, improve communication, or reduce confusion, there’s a value to that. If SMS does not do any of these, then you have the option of not using it.

Anton Chuvakin

AddThis Social Bookmark Button

This poll is especially fun: What are your top challenges with logs and logging? Vote here.

Past polls were:

  • Poll #4 “Who looks at logs in your organization?” (analysis)
  • Poll #3 “What Do You Do With Logs?” (analysis)
  • Poll #2 “Why Collect Logs?” (results so far, my analysis)
  • Poll #1 “Which Logs Do You Collect?” (analysis)
  • Technorati tags: , , ,

    UPDATE: the analysis for this poll is posted. Enjoy!

    Chris Josephes

    AddThis Social Bookmark Button

    I just installed XMLRPC::Lite on a Linux host. You may not have seen this module used too often, but it actually comes bundled in the SOAP::Lite distribution.

    Installation time of one perl module in a 5.8.8 environment? One hour. Was it slow Internet bandwidth? Am I counting the meeting time where we discussed the need for this code? Neither. The install took one hour due to the need to satisfy all of the code dependencies.

    On a host with a default perl installation, I also had to install the dependencies TimeDate, HTML-Tagset, HTML-Parser, MailTools, MIME-Types, Email-Date-Format, Test-Pod, Pod-Escapes, libwww-perl, Crypt-SSLeay, XML-Parser, Compress-Raw-Zlib, IO-stringy, File-Temp, IO-Compress-Zlib, IO-Compress-Base, Pod-Simple, MIME-Tools, FCGI, and Compress-Zlib. I also had to install the openssl-devel and expat-devel RPMs to satisfy the build requirements of some of the modules. And I didn’t get one nice full list of 20 dependencies to be satisfied; I had a list that seemed to grow with each module distribution that I installed.

    I didn’t want to make the job too difficult, because this was a special case server outside of our normal support environment. No RPM packages were readily available, so going through a build process was still the quickest option.

    I’m not angry, but I’ll admit to some frustration and confusion. The first question that will come to my mind is why aren’t some of these modules shipped by default yet? Or, out of all of these modules, how many of them are actually being used?

    Is there anyone using Compress::Raw::Zlib that wouldn’t also want to install Compress::Zlib? Why bundle these modules separately? Are the extra Test and Pod modules really necessary for the end user, or does it just make the developers job easy? And is Email::Date::Format the only module out there that outputs the time in the RFC 2822 time format?

    Again, no harm’s done; but I hope that perl authors and distributors keep this anecdote in mind. The less effort that I need to go through to install your code, the easier my job gets.

    Anton Chuvakin

    AddThis Social Bookmark Button

    I just have to start with this quote from Rich Mogul: “… Legions of armchair futurists slobber over their keyboards, spilling obvious dribble that they either predict every year until it finally happens or is so nebulous that they claim success if a butterfly flaps its wings in Liechtenstein.” :-) Amen to that, Rich. Onwards to my 2008 predictions!

    So, just as in 2006 and 2007, I am coming up with security predictions that cover both technology and market. I just posted a review of my last’s year’s prediction where I mostly erred on the conservative side. I promise to be more ‘extreme’ this year, while still keeping the old wisdom of Richard Feynman in mind: if you predict the status quo, you are more likely to be correct…

    Here is my ‘twitter-style’ (I guess what used to be called telegraph-style :-)) view of predictions in no particular order:

    Platform security:

    • Vista makes us secure = no. People start to actually use it (in large numbers) = maybe. And then get 0wned = yes! The volume of Vista hacking (and then Win 2008 hacking) will increase as the year progresses.
    • Increase in Mac hacking = yes. The story is that Vista drives Mac adoption -> Mac increase in popularity will drive a new wave of Mac “0wnership”
    • Web application hacking still on the growth path = yes. As they say, ‘it will get worse before it gets better.’ I am predicting that 2008 is still the year when it continues to be getting worse.

    Vulnerabilities:

    • 0days use becomes mundane = yes. This will be especially true for those browser-hacking folks who “need” to earn some cash off phishing and other data theft. Thus, “0day use” will no longer constitute news!

    Hacking, data theft, etc:

    • Loss of trust towards legitimate Internet sites = yes. This is manifested by things like this point by the WS guys - more 0wned than malicious sites are used to spread malware. Even now I shudder from the thought that ANY site I visit might be displaying a malicious banner ad which is either bought or “hacked in” by the attackers. The implications of this are pretty horrifying!
    • Major utility/SCADA hack = no (not yet). Everybody predicts this one forever (as Rich mentions), but I am guessing we would need to wait another year or so for this …
    • Cyber-terrorism = no (again, not yet!) Will it be a reality in the future? You bet! Just not now …
    • A massive data theft to dwarf TJX = yes. And it will include not some silly credit card number (really, who cares? :-)), but full identity - SSN and all.

    Malware:

    • The year of mobile malware = no (not yet, if you insist!). As I discussed here, mobile malware is “a good idea” (for attackers) provided there is something valuable to steal (not the case yet in the US)
    • More fun bots = yes. Bots are here to stay: they follow an overall trend for IT automation (seriously!). Think of bot infrastructures as “shadow IT” with their own SLAs, business model innovation, performance optimization tactics, etc
    • Fewer worms and viruses = yes (why write one if you can make money off bots?) As the share of “conventional” viruses and worms in the whole malware universe decreases, so will the popularity of “legacy” AV vendors …
    • Facebook malware/malicious app = yes . This one will be fun to see (others agree), and current malware defenses will definitely not stop this “bad boy.”On the flip side, there is not that much to steal off Facebook accounts …

    Compliance:

    • PCI DSS continues its march = yes. In fact, I bet PCI DSS frenzy will spread downmarket - there is sooooo much more Level 3s and Level 4s compared to Level 1 merchants. They all take CCs, they are all insecure - thus, they will all be 0wned! And then hopefully fined :-)
    • ISO17799, ITIL, COBIT frameworks = maybe (again); they likely won’t be ‘hot,’ at least not in the US; ad hoc approach (with some use of ideas from the above frameworks) to security management will still rule.

    Risk management:

    • Will we know what risk management actually is in the context of IT security = no. Some people (e.g here) might, but not the majority. And don’t even get me started on security ROI :-) This part of security realm will continue to be occupied mostly by loudmouths who will spout, but never define; rant, but never explain; blab, but never clearly state. Sorry to those who are not like this, but you will continue to be in the minority in 2008.

    Security technologies:

    • eVoting security will flare up = yes. Expect big and bad stories about evoting in preparation to the US elections. Maybe another “chad story”, but with an “e-” added to it? Fun, fun, fun! :-)
    • Full disk encryption becomes popular = no. In fact, I predict that in 2008 encryption would be “the new firewall” - more and more people will hide from reality behind “we have encryption - we are safe now!” (check out my piece on encryption mistakes, while you are at it)
    • NAC= huh. Huh? The451Group said it best: “NAC has been the ‘next big thing’ for about four years now - that’s a long time in the IT world.” Others just say “NAC fallout has started.” NAC vs insider attacks? Gimme a break… :-)
    • More whitelisting for host and network security = yes (but combined with blacklisting, which is certainly not going away!) As malware landscape becomes even more diverse, application whitelisting for security will start to shine even more.
    • Academic security research stays ridiculous = yes. Wrong problems, wrong solutions, wrong speed (as in: solving solved problems of day before yesterday…). There will be some exceptions: for example, some of the Project Honeynet academic participants deliver a punch!
    • Secure coding becomes mainstream = no (definitely, ‘not yet’ on this one) It pains me to say that that I think that while this ball definitely started rolling (e.g. SANS is pushing it hard now) it won’t be hurtling down the highway at full speed. 2009? Sure, may be!
    • IPv6 = no (while most think ‘not yet’, some start thinking ‘not ever’) In other words, Internet ’secure by design’ = pipe dream in 2008.

    Security market:

    • Mid-market and SMB security = yes! I think 2008 is the year when smaller organizations will start buying the types of security solutions that were only looked at by the large enterprises before. After all, they have the same problems to solve! They have compliance too. They lose data
    • More security SaaS (software as a service) = yes. It is not just Qualys anymore … More companies will figure out ways to sell security software as a service. This is especially true due to the SMB security spending increase predicted above!
    • ‘Consolidation’ = no. Whaaaaat? You just said ‘no’ to consolidation in security market? :-) Well, Vendor X might buy Vendor Z and Vendor N might go down in flames, but I predict that we will celebrate 2009 with just as many security vendors as we have today …

    Logging and log management:

    • Database logging = yes. 2008 is the year when database logs will be collected and analyzed just as Unix syslog, Windows event logs and firewall logs are collected and analyzed today by just about everybody.
    • Application logging will start = yes. People will start collecting (at least collecting at first) application logs, not just firewall and server OS logs (and database logs, as mentioned above). Maybe ERP, CRM logs, maybe other large enterprise applications will lead the way. Major ‘application logging waterfall’ will occur later, however …
    • Now that collection and management are ‘taken care of’ in many organizations, log analysis will (again…) come to the forefront = yes. In the end of 2008, we will be doing log analysis in a large number of fun, new ways - it won’t just be about rule-based correlation and keyword searching anymore (Andrew agrees)

    Last year’s drag-ons :-) and ongoing trends:

    • Some things make dumb predictions since they are so pitifully obvious and have been going on for years already. Thus, I pile them in this section…
    • So, client vs server exploitation: it started a few years back and will continue, for sure: more client vulnerabilities will be used to 0wn more desktops. Similarly, application vulnerabilities will beat platform ones. And targeted, commercially-driven attacks will overtake indiscriminate ones (another “no-brainer” that some try to sell as a prediction…)
    • Both of the above will power further evolution of network and system security into data and broader information security (it will be happening for another 3-5 years)
    • More fun “web 2.0″ threats will come our way, but then again, this is true about most of the technologies that are being actively adopted …

    Dark horses, that will influence security in a major but unknown way in 2008:

    • Virtualization = people talk about hypervisor security and virtual security appliances as well as other fun stuff (e.g. this), but, in all honesty, we can’t yet fathom the impact that the coming virtualization wave will have on information security.
    • Privacy = I predict that privacy issues, also privacy laws and public outcry due to privacy violations will impact the world of information security in 2008. However, my crystal ball is refusing to share the details on how exactly, citing “privacy concerns” :-)

    Come back in Jan 2009 to see how I did!

    Any comments? Additional predictions?

    Technorati tags: , ,


    Anton Chuvakin

    AddThis Social Bookmark Button

    Even though these posts are from my main blog ( see “Security Warrior” blog) and not from this one, the top posts would still be of interest to my readers here. So, enjoy!

    These are my top popular “Security Warrior” blog posts for 2007! To make this a competition of posts, I am removing the links to the main blog, search labels (e.g. log management, which was indeed one of the most popular resources on the blog) as well as grouping posts together in theme clusters.

    1. Same as during past few months, the “fallout” from being featured on a high-profile programming site continues to drive humongous loads of traffic which made this set of posts the most popular, even for the year. The topic that got such a huge boost was anti-virus efficiency. The posts are: Answer to My Antivirus Mystery Question and a “Fun” Story, More on Anti-virus and Anti-malware, Let’s Play a Fun Game Here … A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation as well as a final entry about my own switch away from mainstream major-vendor anti-virus tool: A Bit More on AV and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga.
    2. Next by rank is a set of my Top11 lists: Top 11 Reasons to Collect and Preserve Computer Logs and Top 11 Reasons to Look at Your Logs (the third list, Top 11 Reasons to Secure and Protect Your Logs, was not quite that popular - I have long argued that, sadly, few people care about log security yet).
    3. Wow! I love, love, love the fact that my blog readers made my first Common Event Expression (CEE), post introducing this emerging log standard, (official site now live!) one of the most popular: Finally, Common Event Expression (CEE) is Out!!!. My other CEE-related posts are labeled here.
    4. Hurray to database logging (finally!) My posts related to database logging top the charts. Specifically, How to Do Database Logging/Monitoring “Right”? as well as its “prequels” :-) Full Paper on Database Log Management Posted and On Database Logging and Auditing (Teaser + NOW Full Paper).
    5. Finally, security ROI saga that flared up mid-year is also among the most popular. Indeed, Security ROI Pile-Up! post made it into Top5 (the related posts are: The Entire Security ROI Blood Trail and ROI, ROSI, RROI and Harry Potter Tales). The rest of my ROI-related posts are labeled here.
    6. At the risk of destroying my math credibility, I will add an item #6 to my Top 5 list, again. This little post called On Open Source in SIEM and Log Management have also generated a lot of traffic and discussion. Indeed, log management vs SIEM as well as reasons for a lack of a popular and complete open source log management solution are fun topics!

    See you in 2009! :-)

    Possibly related posts:

    Technorati tags: , , , , ,