Not to harp, but I’ve enjoyed reading one particular aspect of the conversation surrounding the most anticipated phone of the year, as follows:

A Trade-Off on iPhone Data Speed (John Markoff, NYT): “On the eve of the Apple iPhone’s debut, the top executives of Apple and AT&T today defended their decision to rely upon AT&T’s slow Edge wireless data network, rather than a faster network that is less widely available. Early reviews of the iPhone, while positive, have faulted the slower network because it will limit the palm-sized wireless computer’s utility in making the Internet easily accessible on the go.”

iPhone Blindness (Scott Karp, Publishing 2.0): “Buying an iPhone is like buying a MacBook that only supports dial-up access. [...] How can iPhone reviewers tout the web browser as the “real dazzler” and the “closest thing to the real Internet” when it crawls along like a 1400 baud modem?”

iPhone ‘Surfing’ On AT&T Network Isn’t Fast, Jobs Concedes (WSJ): “Mr. Jobs acknowledged that the company’s new iPhone won’t surf the Internet as fast as he would like on the network, called ‘Edge,’ but added that the device’s ability to connect to Wi-Fi hotspots would give consumers a speedier alternative for Web browsing.”

I think it’s clear that the reviewers equate the utility of mobile browsing with speed. If only there were some free mobile proxy web service that would compensate for the EDGE network’s lower speed without requiring a download and installation. I guess we’ll just have to wait until some enterprising company builds such a thing, or we could wait until all of our favorite websites make cunning little mobile versions. Until then, nobody should buy an iPhone, or any other AT&T phones that surf the so-called mobile Internet! That will teach them.

There has been some complaining about the iPhone’s reliance on AT&T’s EDGE network. Here’s an example from Forbes.com, in sidebar to the article “Why You May Not Want an iPhone“:

The iPhone isn’t equipped for AT&T’s fastest “third-generation” (or 3G) wireless data network. Instead, iPhone users are stuck on an older, slower network, which means Web pages will take longer to load.

Also, since the non-announcement at the WWDC that Apple’s idea of 3rd-party applications is “sites that run on Safari”, there has been additional kvetching. I sympathize with everyone whose software does not translate to the web service model.

However, as a developer who makes a web service that speeds up browsing for mobile devices and doesn’t require a client installation of any kind, I couldn’t be happier about the iPhone design “restrictions”: it validates our approach completely. For the record: Skweezer addresses iPhone slowness without requiring any client installation. So while you’re waiting for Opera for the iPhone, give us a try first. And by the way, we just released Skweezer v4.0 which compresses images too, just in time. Welcome to Skweezer, iPhone people. Enjoy the entire internet.

AT&T or Apple folks: could I have one for testing, please? I’m already a Cingular/AT&T customer. You may already know the Kendall family from my wife’s addiction to the iTunes music store.

Today I stumbled across a post comparing online CSS compression services. More mobile devices support more advanced CSS, so I got to thinking: how could we make mobile CSS work better in Skweezer? Currently it’s either “on” or “off.” I read over the PHP code in the recommended service (very nice!) and I see that it does the following:

• Remove comments and whitepace
• Optionally convert colors to hex values, and shorten hex values where appropriate
• Remove zero measurements
• Sorts the CSS and combines identical selectors
• Combines properties
• Combines or removes empty rules

Because Skweezer also mangles optimizes the original HTML as well, I was thinking that in addition to the above compression techniques, Skweezer has the latitude to do the following operations:

• Remove all properties related to position or advanced CSS that phones can’t use
• Detect and remove browser-specific CSS hacks
• Compress the selector names themselves using a hex identifier
• Embed the CSS in the page if short enough? Not sure on this one…

(Oops, forgot to post this. Moving from “draft” to “published”. Sigh…) One of my high school teachers once told me that he didn’t plan on teaching his son how to type because it would only be a year or two before we’d be interacting with computers by speech and they’d stop including keyboards. In his opinion, typing would shortly become a quaint anachronistic skill. Oh well for that.

The pull of the future is too great, and so for the jillionth time I read today in Slashdot how the cellphone keypad will be reinvented or replaced altogether.

Mobience, which is based in South Korea, has redesigned the ABC and Qwerty key layout, and come up with MobileQwerty. It’s essentially the same three-letters-per-key system as the standard mobile keypad layout, but the letters have been rearranged in a Qwertyesque way to increase efficiency. The other system developed by Nuance is a mobile speech platform that turns speech into text and replaces the keypad altogether.

The first is an incremental layout change, and the second seems as unlikely as my teacher’s Star-Trekian fantasy. I have an idea: what if you could speak directly into your cell phone and then your speech was converted into signals and then those signals were converted to speech on the other end and the listener could just listen to the words without reading them? That would be exactly what we have right now.

Visiting Bloglines mobile through Skweezer has been awesome for quite a while, but at long last the reverse is now true: visiting Skweezer through Bloglines mobile is also awesome. As of last week, Bloglines Mobile uses a custom version of Skweezer to optimize off-site links. This is highly exciting to us. The response on the net has been almost unanimously positive. Kevin has been covering the action, and of course we’re going to PR this properly I’m sure.

However, there was this reaction from Arne Hess of the::unwired, on the other hand:

Ouch, bad news! In my previous posting about Bloglines cooperation with Skweezer, I just wrote: “I hope, Skweezer isn’t trying to skweeze the::unwired since we are serving a mobile device optimized version already which doesn’t needs to be skweezed again.” and indeed, links from Bloglines to the::unwired articles are skweezed. Even worse, not the mobile optimized page is skweezed but the desktop version which results in a completely broken experience.

I tried it out, and sure enough, the::unwired serves up two different versions of each page depending on the user agent. As an experiment, I visited that post with the standard Firefox 1.5.0.7 user agent string, and then again with an old phone user agent, specifically the Motorola 551 (MOT-V551/01.02.03 MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1). The former returned 54.94 KB of HTML, and the later returned the same page that was only 15.92 KB. It is clear that the::unwired adapts page content for mobile devices. As it is today, Skweezer appears as IE 6, and so sites like the::unwired can not perform their magic. I think calling it “a completely broken experience” is a bit over the top, however.

Here’s why. There’s a problem with the Motorola 551 specifically, but shared by many phones that are currently the majority of the current US market. The Motorola 551 simply responds with an error if it receives more than 10 KB of information: “413 Requested Entity Too Large”. Skweezer tries to respect memory limitations and split the content up into pages. Furthermore, if the device supports it, we apply gzip compression to the HTML stream. The end result is that yes, the Skweezer user gets the desktop version, but viewing that post through Skweezer with the Moto 551 UA, the resulting page is only 6.59 KB, well within that phone’s memory limit. Without Skweezer the 551 throws a 413, which is a broken experience, IMHO. Clearly there’s a place for Skweezer to improve even the::unwired’s mobilized pages, even if it does nothing more than gzip. If the::unwired chooses to cater only to devices which can handle more than 20 KB, that is fine. Skweezer will still exist for the rest of the market.

The art of mobilizing pages is always evolving. If you describe what Skweezer does to a programmer (just say “dynamic mobilizing web proxy”), it seems like a 2nd year CS student’s homework assignment. We’ve seen services and companies come and go in this space because, gosh, it just seems so easy. Yes, you can whip together a Skweezer-like service in PHP in 30 minutes if you know your stuff. That service will be 80% decent, and if you limit your testing to your own Treo and your friends’ $600 Smartphones, you may even believe that you’ve got a Skweezer killer on your hands. Believe me when I say that that other 20% is non-trivial. Personally I believe that Skweezer itself is between 90 and 95% complete. To clarify, Skweezer at 100% would be universal and unambiguous improved experience to raw mobile browsing on all mobile devices that have at least 1% market penetration worldwide, when viewing the top 10,000 web URLs. That is just the technical challenge of Skweezing; there’s also infrastructure and the business side of it as well. To sum up this paragraph: mobilizing is much harder to do well than it first appears.

Returning to Mr. Hess’ constructive criticism, however… We are open to adjusting the behavior of Skweezer to account for properly mobilized content as it becomes more commonplace and has better implementations. Last year a survey of sites that self-mobilize (like the::unwired) led us to conclude that masquerading as IE 6 led to the most consistent and user-friendly experience. It is our mission to bridge the gap between mobile users and the web content they’re trying to access in the meantime. I promise to regularly re-evaluate our stance on passing the original UA header, and we may very well do this in a future release. Another possibility is that we could present the user with a choice to leave Skweezer and view the page directly if we detect self-mobilizing, as Mr. Hess suggested. In the meantime, perhaps the::unwired could expand their mobile device definition to detect Skweezer. For the record, we set the “Via” header to “Skweezer”, and our server IP addresses currently start with 65.38.160.x.

I had my misgivings about ESPN Mobile’s service some time ago. Since then, things haven’t gone so well for them, unfortunately. I really mean “unfortunately” because I’d like to see data services do better in America, really. Rising tide and all that.

While reading the news on this, I found a really good writeup on MVNO math by Julie Ask, a JupiterResearch analyst, describing how small this market really is. I have since subscribed to the Wireless section of the JupiterResearch weblogs. Good stuff.

Quick: what kind of mobile phone do you have? You may know the brand, but what’s the model number? Don’t know? You’re not alone, according to this blurb from The Register:

A survey of 761 mobile phone users aged 15 and over, commissioned from Ipsos MORI by LogicaCMG, found that 49 per cent of mobile phone users didn’t know what model they use. A further nine per cent were unaware of the make.

This is a serious barrier of entry for services that require you to know this information before using them, and that translates into lost sales.

I haven’t yet commented on our recent change to Skweezer to discontinue free WebTV access a few weeks ago (a.k.a. MSN TV, but I prefer to call it by the old WebTV name). To recap: since April 24, 2006 if you try to browse Skweezer with your WebTV device and you’re not logged in as a Skweezer Pro subscriber, you get a the following message:

Skweezer® Notification

Hello MSN TV user! Skweezer was developed for mobile phone and PDA users. In order to use Skweezer with your MSN TV device, you need to create a Skweezer Pro account. Click here to sign up for Skweezer Pro, or to update your existing Skweezer account to Skweezer Pro.

If you are not using MSN TV and believe you have received this message mistakenly, please let us know.

It was not done lightly. After all, how cool was it that a completely unintended group of users found a new use for our technology? Theoretically, Skweezer is a perfect fit for WebTV: the content is reformatted for the lower resolution screen, and our dynamic compression really speeds up the web for the mostly dial-up connections. It’s similar to the problem that mobile users have, and we thought that was pretty cool at the time. However, as we experienced rapid growth, it became important to re-examine our traffic patterns to see if there was some way we could improve service quality.

Analysis of the logs revealed that while WebTV clients generated nearly half of our overall traffic they were incredibly unlikely to click our ads, and this became a non-trivial money-loosing situation. Furthermore, the most visited website for WebTV/Skweezer users by far was eBay. You know how people typically use eBay? Refresh, refresh, refresh. Ouch. It is quite likely that someone who’s in the middle of some serious bid sniping is not going to stop to click ads except by accident.

Since our main objection to continuing to support WebTV users was the costly strain they were placing on our servers, requiring the heaviest (and therefore most expensive) users to pay for using Skweezer was a good call, I think. And while there have been some irate individuals who are upset at loosing free access, many others recognized the value and upgraded to Skweezer Pro. It works out to about $1.25 per month. In fact we approached MSN and suggested that they sponsor a co-branded version of Skweezer, but there was no interest.

While the imminent death of WebTV has been proclaimed repeatedly, in the meantime there are plenty of customers who could use a little help. While we can’t afford to run a charity, we’re happy to welcome the many new WebTV/Skweezer Pro users who have proactively addressed the shortcomings of their chosen platform.

Over at Ars Technica, I saw the article Mobile phone users love their pornography. Yes they do, but we already knew that. Ars said this also, regarding the disparity between phones and PDAs:

One of the study's more intriguing findings concern is the relative virtue of PDA users. While 20 percent of mobile phone queries are for adult material, only five percent of PDA searches are for porn. Despite the larger screen, PDAs are apparently not mobile porn platforms. The authors chalk this up to the "business-oriented use cases of these devices" and the "potentially different demographic of users" (read: fewer 17-year-old boys own a PDA).

That may be, but there's probably a simpler explanation: text input method. Sorry to be gross. But beyond this specific topic, I think this is useful research on how device input format has a direct and measurable impact on search and browsing behavior. Are you more likely to tap out a search with a stylus or T9 it with a keypad? Remember, this study was about searching, not browsing. But for selecting links on a page, a stylus beats a joystick any day as long as you can devote two hands to the task. OK, ewww. This post is done now.

After some recent infrastructure changes, many users complained that they were unable to connect to Skweezer with SSL, which our log in page requires. Some phones would just show an unhelpful error like 513 or 503, page cannot be found. My Nokia popped up a strange error though, claiming that the server certificate expired even though the certificate expires next July. However, some browsers and phones had no problem at all establishing SSL. It turns out that there was nothing wrong with the certificate, and that's where it gets really weird.
According to this knowledge base article at Microsoft:

The previous VeriSign 128-bit International (Global) Server Intermediate certification authority certificate expired on January 7, 2004. This may cause problems for clients that try to establish server-authenticated secure socket layer (SSL) connections with Web servers and other SSL/Transport Layer Security (TLS)-enabled applications that do not have up-to-date certificates.

To prevent these problems, Microsoft Internet Information Services (IIS) operators should contact VeriSign to update the intermediate certification authority certificates for servers that use 128-bit SSL to connect to Web sites with the Secure Hypertext Transfer Protocol.

Impact: Clients cannot establish SSL-protected connections to Web servers that do not have updated certificates.

Recommendation: Install the updated version of the VeriSign intermediate certificate.

What they were saying is that VeriSign's own certificate expired, and so any certificates that pointed to it (like ours) might not work. You may not experience this problem on your desktop if you're browsing with Windows for example, because Microsoft keeps your list of certificate authorities (CA) up to date if you use automatic update, and so the end result is that your computer automatically trusts VeriSign. Many phones are not like this, however, and they may need to fetch a copy of the intermediate CA certificate in addition to the site certificate. Do they get that certificate from the CA directly, like you'd expect? No, you have to keep an up-to-date copy on your web server. This problem is specific to VeriSign certificates it seems; other certificates have a pointer called the AIA extension that reduces the chance of this happening. Does Microsoft automatically update your CA list just like they automatically update everyone's desktop computers, as part of the "Microsoft Root Program"? Of course not. It's your responsibility to keep the intermediate certificates on your servers up to date. This is frustrating to say the least.

To fix this problem, we had to get a new certificate from VeriSign that expires in 2011 and install it on each web server. This becomes part of the server installation procedure. Believe me, I'll be looking at alternatives to VeriSign before we have to renew. After all, the reason we went with the pricy VeriSign certificates instead of other companies was because theoretically VeriSign has greater compatibility and thus less problems with older browsers. Lesson learned.