It has been widely reported this week that Google has formally announced plans to kill off Google Talk, its original popular IM product which (for most of us) was supplanted by “Hangouts” a few years back.

I still think that Google Talk was the high-water mark for Google’s “over the top” (OTT) chat efforts; it was reliable, standards-based, interoperable with third-party clients and servers, feature-rich, and well integrated with other Google products such as Gmail. You could federate Google Talk with a standard XMPP server and communicate back and forth across domains, or use a third-party desktop client like Adium or Pidgin. Google Talk message logs appeared in Gmail almost like email messages, making them easy to backup (you could retrieve them with IMAP!) or search.

Looking back on those halcyon days, we hardly knew how good we had it.

Everything Google has done since then has made the basic user experience gradually more shitty.

Today, Hangouts works with Adium and Pidgin sometimes, depending on what Google has done to break things lately. XMPP federation with other servers is being disabled, for no good reason that I can tell, in the near future, finally making it the walled garden that Google apparently wants. Integration with other products is inconsistent: to use some Hangouts features, you need to use the primary web interface (hangouts.google.com), but other key features — message search being the biggest one — are missing entirely, and require you to go into Gmail. Gmail! Why the fuck do I need to go into my email client to search my messaging logs? Who knows. That’s just how Google makes you do it. And of course in Gmail, Hangouts logs are no longer stored as emails, they’re some bizarre format where logs are broken up arbitrarily into little chunks (sometimes one log chunk per message), and in some cases there’s no way to get from a message in Gmail’s search results back to a coherent view of the conversation that it occurred in.

In the meantime they added voice, which is sorta neat but nobody I know really uses, and video / screensharing, which is very cool but uses its own web interface and seems suspiciously like a bolt-on addition.

Basically, Hangouts is broken.

But rather than fix it, Google seems determined to screw it up some more, in order to turn it into an “enterprise” messaging system (read: doomed Slack competitor). On the chopping block in the near term is the integration of carrier SMS and MMS into the Hangouts mobile app. I guess because enterprise users don’t use text messages..? Only Google knows why, and they’re not saying anything coherent.

For us poor plebs, they created “Allo”, a WhatsApp clone combining all the downsides of OTT messaging and carrier SMS into one shit sandwich of a product. (Just the downsides of carrier SMS, like requiring a POTS phone number; it doesn’t actually do carrier SMS, of course. That’s a new, separate app.) The sole deal-sweetener was the inclusion of Google Assistant, which could have just as easily been added into Hangouts. But instead they made it an Allo exclusive, ensuring that nobody really got to use it. Bravo.

Here’s the worst part: Hangouts is broken, Google is not going to fix it, and the best alterative for Joe User right now is … drumroll, please … Facebook Messenger.

That’s right, Facebook Messenger. Official platform of your 14-year-old nephew, at least as of five years ago, before he moved on to Snapchat or something else cooler. That’s the competition that Google is basically surrendering to. It’s like losing a footrace to someone too stupid to walk and chew gum at the same time, but only because you decided it’d be fun to saw your own legs off.

In fairness — very, very grudging fairness, because Facebook at this point is about one forked tail away from being Actually The Devil Himself in terms of user-hostility — Facebook Messenger isn’t… all that bad. I can’t believe I just wrote that. I feel dirty.

However, it’s hard to avoid: Facebook’s Messenger is just the better product, or is likely to become the better one soon. Let us count the ways:

• It has the userbase, because everyone with a Facebook account also has a Messenger account. However it doesn’t require FB membership to use Messenger: you can create a Messenger-only account by validating a phone number (much like WhatsApp or Signal or Allo). So it’s got all of them beat there, and network effects mean that the number of people already using the service is always the most important feature of a messaging service.

• It allows end-to-end encryption but isn’t wed to it (as Signal is), meaning it can do things that are hard to do in a 100% E2E encrypted architecture, like letting you simultaneously use multiple devices in the course of a day and have all your messages arrive to all of them. All your logs can be searched from any device, too.

• Speaking of logs, Facebook already has better facilities for searching your past conversations than Hangouts. (The only service that seems to be better is Slack, which is somewhat ironic given that Google apparently wants Hangouts to be its Slack competitor, and Google can’t beat Slack at the one thing that you’d expect Google to actually do well.) Finding a conversation based on a keyword and then being able to read it in context is already far easier from Messenger’s website than from Gmail’s, and of course you can’t search conversations from Hangouts’ main website at all.

• On mobile, at least on Android, the Hangouts app is better for the moment, but I don’t expect that to stay the same once Google starts forklift-upgrading it to be “enterprisey-er”. And the Messenger app isn’t terrible (unlike the main Facebook app, which is an unstable battery- and data-hogging testament to bad ideas poorly implemented). The recent inclusion of Snapchat-like features nobody really asked for notwithstanding, Messenger does its job and has some occasional nice features, like very low-friction picture and short video messaging. At least on my device, it hasn’t crashed or ANRed in as long as I can remember.

Personally, I’ll probably continue to use Hangouts until the bitter end, because I’m lazy and resistant to change, but I suspect Messenger is where most of my friends are going to end up, and those who don’t want to do use a FB product will largely just end up getting carrier SMS/MMS messages again.

Congrats, Google. You could have owned messaging, but you screwed it up. You could probably still salvage the situation, but nothing I’ve seen from the company indicates that they care to, or are even capable of admitting the extent of their miscues.

Echoing the theme of an article I read yesterday, about the FCC’s intentional — or at best negligent — duopoly in wired broadband, is this article about the current “5G” hype, and how it seems to be assisting the big telcos in disguising their under-investment in FTTH / FTTP in favor of more-profitable wireless services:

The Next Generation of Wireless — “5G” — Is All Hype

The author writes:

Cynics might point out that by waving their hands around about the coming miracle of 5G — even though its arrival is really a long way off — carriers are directing attention away from the terrible state of fiber last-mile infrastructure in the US. Call me one of those cynics. This kind of misleading tactic isn’t difficult to pull off in the U.S. […] A leading tech VC in New York, someone who is viewed as a thought leader, said to me not long ago, “Why do you keep talking about fiber? Everything’s going wireless.”

This is eerily similar to claims used by the telco and cablecos to justify diminished regulation, by pointing to BPL. The major justification for eliminating ‘unbundling’ regulation, and for not applying it to cable lines at all, was because consumers were going to be able to obtain Internet service over a variety of last-mile circuits, including cable lines, telephone lines, fiber, and power wiring. This, of course, was horseshit — BPL was always a terrible idea — but it was just plausible-enough to keep the regulators at bay while the market condensed into a duopoly.

Given that the telecommunications companies want nothing other than to extract maximum economic rents from consumers for as long as they can, while investing as little as they possibly can for the privilege — this is how corporations work, of course, so we shouldn’t be especially surprised — we should treat the 5G hype with suspicion.

No currently-foreseeable wireless technology is going to reduce the need for high-bandwidth (read: fiber-optic) backhaul; 5G as envisioned by most rational people would, in fact, vastly increase the demand for backhaul and the need for FTTH/FTTP. Be on guard for anyone who suggests that 5G will make investments in fiber projects — especially muni fiber — unnecessary, as they are almost certainly trying to sell you something, and probably nothing you want to buy.

After switching from my venerable Nexus One to a new Samsung Galaxy SII (SGS2) from T-Mobile, I was intrigued to discover that it has a fairly neat WiFi calling ability. This feature lets the phone use a wireless IP access point to place calls, in lieu of the normal cellular data network. On one hand it’s a bit of a ripoff — even though you’re using your own Internet rather than T-Mobile’s valuable spectrum, they still use up your minutes at the same rate; however, it’s nice if you travel to a place with crummy cell service but decent wireless Internet.

When the feature is enabled, the phone will switch preferentially to WiFi for all calls, once it pairs to an access point. (It can be disabled if you’d prefer it to not do this.) There are still some very rough edges: the biggest issue is that there’s no handoff, so if you place a call over WiFi and then walk out of range of the AP, the call drops. Whoops.

I was curious how the calls were actually handled on the wire, and in particular how secure things were. To this end, I decided to run a quick Wireshark analysis on the phone, while it was connected to my home WiFi AP.

The setup for this is pretty trivial, and out of scope of this entry; basically you just need to find a way to get the packets going to and coming from the phone to be copied to a machine where you can run Wireshark or tcpdump. You can do this with an Ethernet hub (the old-school method), via the router’s configuration, or even via ARP spoofing.

With Wireshark running and looking at the phone’s traffic, I performed a few routine tasks to see what leaked. The tl;dr version of all of this? In general, Android apps were very good about using TLS. There wasn’t a ton of leakage to a would-be interceptor.

Just for background: Gmail and Twitter both kept almost everything (except for a few generic logo images in Twitter’s case) wrapped in TLS.

Facebook kept pretty much everything encrypted, except for other users’ profile images, which it sent in the clear. This isn’t a huge issue, but it does represent minor leakage; the reason for this seems to be that Facebook keeps the images cached on a CDN, and the CDN servers don’t do SSL, apparently. I’m not sure what sort of nastiness or attacks this opens up, if any (perhaps social engineering stuff, if a motivated attacker could recover your friends list), but it’s worth noting and keeping in mind.

I next confirmed that text messages (SMSes) aren’t sent in the clear. They are not, although I’m not 100% sure they’re even sent over the data connection — it’s hard to tell, among the SIP keepalives, whether a SMS went out via the WiFi connection, or if the phone used the actual cell-data connection instead. Sometime when I’m in a location without any GSM coverage but with WiFi, I’ll have to test it and confirm.

Last, I made a quick call. This is what I was most interested in, since encrypted SIP is surprisingly uncommon — most corporate telephony systems don’t support it, at least not that I’ve seen or worked with. It wouldn’t have surprised me much at all if the SIP connection itself was all in the clear. However, that doesn’t seem to be the case. The call begins with a sip-tls handshake, and then there are lots of UDP packets, all presumably encrypted with a session key negotiated during the handshake. At any rate, Wireshark’s built-in analysis tools weren’t able to recover anything, so calls are not script-kiddie vulnerable. Still, I’m curious about what sort of certificate validation is done on the client side, and how the phone will react to forged SSL certs or attempts by a MITM to downgrade the connection.

Certainly lots of room for further experiments, but overall I’m relieved to see that the implementation isn’t obviously insecure or vulnerable to trivial packet sniffing.

I discovered earlier today, while trying to load my personal X.509/SSL certificates onto my trusty Nokia E61i, that its personal-certificate support is for all intents and purposes intentionally broken.

When the user certificate is imported to Nokia Eseries devices, e.g to be used for authentication with WLAN connections, the certificate contents are checked and if there’s any issues with the certificate fields, the importing of the certificate will fail and the error message “Private key corrupted” is shown.

One common situation where this problem may occur is if the KeyUsage field in the certificate has the nonRepudiation bit enabled. A certificate with nonRepudiation bit is rejected by E60, E61, E61i, E65 and E70 devices because of the security reasons.

The workaround is to create a new user certificate where the nonRepudation bit is removed. The nonRepudiation bit is not necessary when doing a certificate based authentication e.g. in WLAN environments.

Yes, broken. I don’t care what the Nokia engineers were thinking when they put that “feature” in, it sucks. It basically stops you from using 99.9% of all certificates in the world — ones produced using the default settings from most issuers, and forces you to generate a brand new certificate for the device. That is totally unacceptable. Certificates cost money in many cases, and even if they don’t, they take time to create. Plus, managing multiple per-device (rather than per-user) certificates is a royal pain in the ass.

Nokia’s “solution” to the problem would force me to generate a brand-new certificate for my mobile, and then I’d need to replace the certificates stored on every other device with the new one, in order to make sure I can decrypt S/MIME email. If I didn’t do this — if I used one certificate on the E61 and another on my desktop and laptop, the E61 wouldn’t be able to open encrypted email sent in response to messages originating from the other machines.

(This is all assuming the E61i can even do S/MIME, which I’m not 100% sure of; but since it can’t load my certificate, it’s a bit of a moot point.)

Hardcore failure on Nokia’s part. Security, no matter how well-meaning, is worse than useless if it breaks functionality or makes the user’s life this difficult. All it does is raise the ‘cost’ of security, and make it more tempting to forgo things like certificate-based authentication at all.

Up until recently I’ve been pretty happy with the E61i, but I’m feeling more and more that they just didn’t take core functionality seriously enough. The software is flaky and unreliable, as is the Bluetooth stack (I get lockups about once a week when I’m using it with a BT headset or tethered to a laptop), and I question whether anyone who worked on the built-in email client actually used it. (When you have an entire QWERTY keyboard to work with, why does every action require at least 3 clicks on a miniature D-pad?) It does have its charms — JoikuSpot is amazingly useful, and I love not being locked into an iPhone-style “App Store” — but the warm fuzzies are really wearing off.

It’s starting to become clear to me why BlackBerry, and not Nokia, is so dominant among users who actually care about communication over everything else. (BlackBerry offers both S/MIME and PGP, although it seems like it may need to be deployed to an Enterprise Server rather than to individual handhelds.) It’s just unfortunate that the BlackBerry offloads so much intelligence to the BES/BIS backend; I’m not really comfortable being that tied-in to somebody else’s infrastructure, and I don’t really feel like running my own BES.

Maybe it’s time to take a look at Palm.

According to a post on the Full Disclosure mailing list, history has repeated itself: T-Mobile’s systems have apparently suffered a serious breach, and a lot of customer data has been compromised. Oops.

The last time something like this happened to T-Mobile, it was due to a known vulnerability in BEA’s WebLogic application server that T-Mobile had failed to patch correctly. Although the ‘hacker’ in question ended up in the Federal pen for his trouble (one hopes the celebrity email-reading was worth it), and a lot of attention seems to have been paid to the Secret Service’s identification and capture of him, the real culpability was T-Mobile’s. By failing to patch their servers, they left them wide open to infiltration.

It’s a bit too soon to tell whether the latest break-in was similarly due to technical incompetence at T-Mobile, or if they fell victim to some other method. However, it doesn’t sound like the ‘cybercriminals’ behind it all are the sharpest pieces of cutlery in the drawer. Unless they’re playing an amazingly deep game, I think it’s safe to say they didn’t think their cunning plan all the way through.

From the FD post:

We already contacted with [T-Mobile’s] competitors and they didn’t show interest in buying their data -probably because the mails got to the wrong people- so now we are offering them for the highest bidder.

Sounds almost petulant, doesn’t it? “Probably because the mails got to the wrong people” — really? They seriously think that’s the problem? If only they’d had the contact information for the Espionage Division of AT&T, the whole thing would have gone so smoothly!

They would have done better to read up on the Coke / Pepsi trade-secrets bust from back in 2006. A disgruntled Coke employee stole the secret Coke formula and tried to sell it to Pepsi, but Pepsi — much to her surprise, I’m sure — pretty much fell over itself notifying Coke of the offer, and then worked with the Feds during the ensuing investigation. Although the press coverage tried to make a heart-warming after school special out of the whole thing, Pepsi’s behavior should have been predictable and obvious: the risk of getting caught with stolen trade secrets from their fiercest competitor so greatly outweighed the value of those secrets, there was no way they would ever take the thief up on her offer.

The very same situation now exists for the morons who stole the data from T-Mobile. What competitor would even think of touching it? What could any competitor possibly gain from the data that would be greater than the huge downside risk, and could not be obtained more easily some other way? I can’t think of anything. Even if the files were totally complete, and represented dossiers on every one of T-Mobile’s customers completely documenting their behavior and preferences with regards to cellular telephony, it still wouldn’t be worth the near-certain chance of getting busted down the road, when T-Mobile notices a startlingly high number of their subscribers getting poached.

The smartest thing for AT&T, Verizon, Sprint, et al to do, on receiving an offer to purchase obviously stolen records, would have been to immediately report it to the Feds. That they didn’t makes me guess that they probably didn’t even take the offer seriously. How humiliating!

After failing to sell the goods (which I suspect are database dumps) to T-Mobile’s competitors, the thief or thieves then decided to just post a for-sale ad to the Full Disclosure mailinglist — well known in IT security circles, but not known as a clearinghouse for stolen identities. It’s not as though there aren’t venues on the ‘net where trading and selling identity information is common — supposedly there are whole online communities for this purpose — but the FD list certainly isn’t one of them. The only way they could have been more bush league is if they’d used Craigslist. Or maybe Ebay.

So that brings me to two possible conclusions about the whole breach:

1. It was conducted by someone of questionable technical competence (at this point it’s too early to tell), but dreadful business skills, who couldn’t resist undermining the commercial value of the information they stole in order to claim credit in a high-profile way. They chose the FD list rather than some more appropriate sales channel because the FD list gets read by a fair number of security experts, and this means more geek cred. Of course, what ‘geek cred’ gets you in prison is beyond me. (Maybe Hans Reiser knows.)

2. It was conducted by someone who knows exactly what they’re doing, and what we’re seeing is a carefully-constructed ruse of some sort. There might not be any information to sell, or else selling the information at a maximum profit might not be the real goal. Instead, the purpose would be to embarass and tarnish T-Mobile’s reputation as badly as possible.

Admittedly, option #2 does get a little tinfoil-hatty. To profit from it, someone would need to build up a huge short position in DT stock (or certain futures contracts), and hope that the news of the breach would cause the value to slide. However, I don’t even know if this would be realistic: DT is a huge company, and T-Mobile USA is only a part of it. Even a cataclysmic security breach might not do more than wiggle the needle of DT’s share price, requiring a huge position or lots of leverage to take advantage of it.

Neither theory bodes well for the people behind it; according to option #1 they’re clearly incompetent and far beyond their depth as far as professional criminality is concerned. Not exactly a hard target for law enforcement. According to option #2 they’re less stupid, but still at a huge disadvantage: the position they’d need to have built up to profit from the security breach would be visible in retrospect, possibly even obvious. Even spread between lots of accounts, I suspect it wouldn’t take long for the forensic accountants to catch on.

It will be interesting to see how everything pans out in the next few weeks. There is no scenario where it looks good for T-Mobile; those who, like me, are T-Mobile customers can only hope that this time they’ll learn the lesson a bit better, and put some more effort into security.

This is just a quick breakdown, as far as I’ve been able to determine, of which models will allow you to access the ‘net through them, and which are too braindead/broken/Windows-centric. (This is not necessarily an exhaustive list, and is not guaranteed to be correct! Be sure to do your own research before purchasing or signing a contract.)

Options to consider:

• BlackBerry 8800 (GSM)

Reported to work; source is Tom Yager of Enterprise Mac. The discussion forum on Fibble.org also has some instructions. This seems to be the starting point for most of the 88xx variants.

• BlackBerry 8820 (GSM and WiFi)

Reported to work by BlackBerryForums member “CatherineLW”, via Bluetooth only.

• BlackBerry 8830 (CDMA and Euro-GSM)

Reported to work via Bluetooth, not via USB. Follow-up article here. It’s also described as working (in “exactly 2 minutes”) in this article.

• BlackBerry 8300 “Curve” (GSM)

Reported to work. Page includes links to required modem script and information on init strings. In the comments there are intermittent problems reported, so it’s apparently not a foolproof solution.

All information seems to relate to Bluetooth tethering; there’s no mention of success (and lots of failures) trying to tether via USB. Apparently USB tethering is, for some reason, only possible from Windows.

• BlackBerry 8320 (GSM and WiFi)

The 8320 is a special version of the 8300 made for T-Mobile; it includes some additional features including 802.11a/b/g UMA calling.

There are some scattered reports indicating that it works, and some others saying that it doesn’t. It seems like it ought to work; problems may relate to bad software revisions.

• BlackBerry 8100 “Pearl”

Reported as working by Dave Taylor of AskDaveTaylor.com, and Grant Goodale of Fibble.org.

However there are serious issues with particular software revisions. Software version 4.2.1.107 in particular, which was pushed out to T-Mobile phones, is known to have issues.

Options to avoid:

• BlackBerry 8700

For some reason, normal Bluetooth DUN methods don’t work with the 8700 series, which is unfortunate because it’s relatively inexpensive and in all other respects a nice phone (particularly the ‘G’ revision).

There’s a whole saga of efforts, including a substantial ‘bounty’, put towards getting this thing working as a USB or Bluetooth-tethered connection, but there doesn’t seem to be a very satisfactory solution. The closest anyone seems to have gotten is a $50 software package called “Pulse” which allows tethering via a proxy server that you must run (or pay for the use of), through which all traffic flows. Although I appreciate the effort involved, this doesn’t strike me as particularly elegant — frankly it’s unacceptable that it’s even necessary. Anything that requires that much of a workaround to use is broken.

The bottom line:

It’s not really much of a surprise that RIM doesn’t seem to focus very heavily on anything except Windows, given their established userbase in the corporate market, but it’s still a bit disappointing. The best BB device for Mac users at the current time seems to be one of the 8800 series, either the 8800 itself (currently retailing for $280) or the 8820/30 variants depending on whether you want GSM or CDMA service within the US. Either the Curve or the Pearl would seem to be a close second; I only give the 8800 an edge because it’s newer, and will probably be getting more attention for longer than either of the older models.

While this isn’t breaking news or anything, Jeff Starr has a nice tutorial posted over at PerishablePress.com, explaining how to set up a BlackBerry Curve as a Bluetooth DUN device with a Mac. This allows you to connect to the Internet from the Mac via the BlackBerry, provided you have a data plan that supports ‘tethering’. (This includes — to my knowledge anyway — all T-Mobile unlimited data plans including ‘BlackBerry Unlimited’, but only some AT&T plans.)

The solution is of the same form as for most other modern phones: a custom modem script that gets dropped in /Library/Modem Scripts/ and a CID string that tells the phone to open a data connection to the network.

The instructions are specifically for the Curve, aka the 8300, but a very similar procedure works for the 8800, with a slightly different modem script. (Also see this EnterpriseMac article.)

A while back I wrote up a little ‘mini-HOWTO’ on connecting to the Internet via a T-Mobile cellphone from a Mac running OS 10.4. (It’s been a while since I’ve tried it, but I think all the information is still current.)

For a bunch of reasons that are well outside the scope of this blog, I had reason recently to try and do the same thing from a Windows PC. Although I’m sure the process makes sense to somebody, I didn’t find it particularly intuitive. Just in case there’s someone else out there trying to do the same thing and struggling, I thought I’d provide pointers to the online resources I found most helpful.

This page from the HowardForums Wiki was one of the most useful and concise. In fact, it seems to be by far the most referenced document on the topic.

Most of the problems I ran into were related to my Bluetooth adapter. Unlike in OS X or Linux, where Bluetooth is handled by an OS component, Windows delegates it to a driver provided by the manufacturer. Like virtually all software produced by hardware manufacturers (scanner software, anyone?), I’ve yet to see one that wasn’t a flaky pile of crap. It’s what you get when you’re viewed as a ‘cost center’, I guess. Once you’ve gotten the phone and computer to pair, you’re about 50% done.

The HowardForums instructions tell you to configure the Bluetooth WAN connection by going into the ‘Network Settings’ control panel; on my system (Dell Inspiron 9400 with onboard Broadcom adapter) this was not correct. The network connection for the Bluetooth device connected using a ‘device’ called a “Bluetooth LAN Access Server Driver”. To configure it, I had to go through the My Bluetooth Places folder, and configure the “BluetoothConnection” in the Bluetooth Properties window. It was in that window (“BluetoothConnection Properties”) rather than in the Network Connections panel, where I could enter the ‘phone number’ used for WAN access.

With that done, the next step is to add the correct initialization string for the APN you want to use. This is all pretty much as the HowardForums article directs. If you are on the low-cost “TZones” plan, you’ll need to use ‘wap.voicestream.com’ as the APN, making the init string at+cgdcont=1,"IP","wap.voicestream.com". You’ll only be able to connect via an HTTP proxy, but it’s six bucks a month (and probably a TOS violation) — what do you expect?

In theory, with the phone number and init string entered, the Network Connection created, and the phone successfully paired to the computer, you’d be good to go. However when I tried to connect, I just got a repeated “Error 692: There was a hardware failure in the modem” error. The ‘Error 692’ problem is apparently not uncommon, and has various solutions that seem to work for different people, with no discernible rhyme or reason. In my case, the problem was due to a leading space that had crept into the init string when I copied it from HowardForums. When that was corrected, I was able to bring the connection up.

It’s so slow that really I’d only consider using it either in an emergency or times of unbelievable boredom, though it does work after a fashion. However, the same procedure allegedly works for EDGE just as well as GPRS, so when I eventually get that EDGE-compatible phone (and get the real data plan), I’ll hopefully be all set.

As reported by a large segment of the Technorati crowd, Walter Mossberg recently wrote a nice piece on the current state of the U.S. cellphone market, and why it, for lack of a better word, sucks so much. The key is all in the subsidized phone racket.

[The] whole cellphone subsidy game is an archaic remnant of the days when mobile phones were costly novelties. Today, subsidies are a trap for consumers. If subsidies were removed, along with the restrictions that flow from them, the market would quickly produce cheap phones, just as it has produced cheap, unsubsidized versions of every other digital product, from $399 computers to $79 iPods.

I think he’s the first mainstream journalist that I’ve read who has really gotten this. Phone locking, enforced mutual incompatibilities, application restrictions — the entire culture of control — all springs from subsidies. If people just bought their phones outright, they’d probably be significantly cheaper (not to mention more full-featured), there would be a greater secondary market (meaning less waste), and they’d be more prone to shop for networks based on price, service, and quality.

Perhaps as it becomes more obvious that the iPhone is, despite being (in Mossberg’s words) “the best-designed handheld computer ever made,” a costly white elephant because of carrier-mandated restrictions, there will be greater national conversation about the state of cellular telephony.

As Mossberg points out, we’ve been through this with landline phones before, prior to the disassembly of AT&T as the national monopoly carrier. It took almost a century for consumers to get first comfortable with the technology, and then impatient with the restrictions placed upon it: I don’t think cellular will take that long.

A little while ago I finally succeeded in getting mobile internet working through my phone, my Mac, and a USB cable. Although not exactly something that deserves to be in the software configuration hall of fame, the end result — internet on my laptop, via my cellphone’s GPRS connection — has a fairly good ‘wow’ factor. However, it’s not the sort of thing most non-technical people are going to be able to set up easily.

And so, with that audience in mind, I wrote up my experiences in the form of a “mini-HOWTO”. It’s a quick explanation of how to get one particular hardware configuration working, step by step. Since the hardware I’m using isn’t that uncommon (a bog-standard Motorola V3 “Razr” phone, with service though T-Mobile, a Mac laptop running the currently-latest version of the OS, and a mini-USB cable), I hope maybe it’ll be of use to somebody else, somewhere on the internets.

Permanent link here. I tossed it up there as GFDL, so if anyone would like to redistribute it, or use it as the basis for a more general HOWTO, feel free.