{"id":510,"date":"2008-03-14T21:06:22","date_gmt":"2008-03-15T05:06:22","guid":{"rendered":"http:\/\/wapreview.com\/?p=510"},"modified":"2008-03-14T21:06:22","modified_gmt":"2008-03-15T05:06:22","slug":"sprints-openweb-no-upgrade","status":"publish","type":"post","link":"https:\/\/wapreview.com\/510\/","title":{"rendered":"Sprint’s “OpenWeb” No Upgrade"},"content":{"rendered":"

\"SprintLast week Opera released a minor upgrade to the Opera Mini browser. I like to follow the latest releases so I downloaded it to all my phones from mini.opera.com<\/a>. I used each phone’s built-in browser so Opera could detect the phone model and send the optimal version of Opera Mini. All went well until I tried to upgrade my Samsung A920. I got a message “Your phone model could not be detected” This seemed strange as Opera had recognized the A920 in the past.<\/p>\n

I though maybe something was broken on Opera’s side. So I went to the page Opera provides for users to report undetected phones, mini.opera.com\/detect<\/a>, and was surprised that the phone’s User Agent was “Mozilla\/5.0 (compatible; OpenWeb 5.6.1.3-03) Opera 8.54<\/em>“. That’s wrong, the A920 UA should be “Samsung-SPHA920 AU-MIC-A920\/2.0 MMP\/2.0 Profile\/MIDP-2.0 Configuration\/CLDC-1.1<\/em>“.<\/p>\n

It seems my carrier, the US CDMA\/EVDO provider Sprint PCS<\/strong><\/em>, is unilaterally running all web traffic though Openwave’s OpenWeb<\/a><\/em><\/strong> reformattting transcoder which is replacing the phone’s User Agent header with it’s own.<\/p>\n

The User Agent is the only way that mobile sites can identify the phone model and optimize their markup for different screen sizes, Javascript support, etc. If a proxy or transcoder changes the User Agent sites can’t deliver an optimal web experience. It’s even worse for providers of content like ringtones, games, wallpapers. Without the User Agent there is no way for the provider to know which content is compatible with the phone.<\/strong> The big multi-national carrier Vodafone <\/a>has gotten a bad name<\/a> with mobile developers for implementing similar transcoders from Novarra, Openwave and Bytemobile.<\/p>\n

It actually looks like with this implementation for Sprint, Openwave is trying to sort of do the right thing<\/strong> and send the original User Agent if it detects mobile content. The detection seems to work with many sites that send only mobile content from a given URL. Opera delivers PC or mobile content from mini.opera.com depending on whether it detects a full-web browser or a mobile one. Opera’s multi-serving of content seems to confuse Openwave. And it’s not just Opera, users at the independent site SprintUsers.com<\/a>, are reporting problems with several free ringtone sites including Rumkin.com<\/a> and FunForMobile.com<\/a><\/p>\n

It’s not easy to programmatically determine if a site is designed for mobile devices. You can’t rely on the Mime type or Doctype, there are lots of tag soup mobile sites served as text\/html. Bad practice perhaps, but those sites work. And really, I don’t understand why OpenWave changes the User Agent in the first place. There’s nothing about the process of transcoding that requires changing the User Agent to function. The mobile web works best when sites can identify mobile handsets by User Agent. <\/strong>If the site sends mobile content no transcoding is needed. I’ve heard the excuse that transcoders need to send a desktop browsers User Agent because there are a handful of badly written full web sites that return an error or empty page when confronted with a mobile user agent. I’d be OK with a transcoder retrying with a desktop User Agent in those cases only, but not in the case of sites like mini.opera.com or Rumkin which return a usable page to ALL browsers and mobile content to mobile browsers. I’m forced to suspect evil intent, nothing else makes sense. It’s as if Openwave is changing the User Agent to fool multi-serving sites into delivering non-mobile content so that their transcoder can have more work to do and they can claim to have “fixed” a higher percentage of sites.<\/p>\n

Don’t get me wrong, I’m not opposed to transcoding, I use and recomend Mowser, Skweezer and Google GWT for viewing full web sites on the limited built in browsers of feature phones like the A920. But I opt to use them and at the bottom of every transcoded page in all three of those transcoders there’s a link to view the original untranscoded page. Sprint has imposed OpenWeb on their users without any warning and with no way to opt out.<\/strong><\/p>\n

Even though I don’t like this transcoder being forced down my throat, it wouldn’t be so bad it if it improved the mobile web experience. I decided to spend the day using the Obigo Browser and OpenWeb transcoder instead of my normal Opera Mini.<\/p>\n

First I tried Bloglines Mobile<\/a>. I loaded my subscriptions list and clicked on the the first of my feeds, GigOm<\/a><\/em> which had 4 unread items. After a long delay, OpenWeb reported that Bloglines had refused the connection<\/strong>. I retried and the GigOm feed loaded but there were no longer any unread items. Bloglines marks items read when you load them so it seems unlikely that Bloglines actually refused the connection. I think that Bloglines got the request, returned the page with my unread items and then an error occurred within OpenWeb causing it to loose my page. The error message blaming Bloglines seems bogus. If the server had actually refused the connection the Bloglines script would never have seen the request and my items would still be unread. I tried three more feeds and they loaded without error so this is a transient issue. Later, I got the refused connection error again, this time on the SMS Text News<\/a><\/em> feed and lost several more unread items. Going for broke I next I tried loading all the unread items (about 30) in all my feeds as a single page, something I often do with Opera Mini. This actually worked, OpenWeb split the big page up into 9 little ones with no errors this time. I was mildly impressed although it didn’t make up for the earlier problems.<\/p>\n

Next, I tried the mobile web version of gMail. On the login page OpenWeb showed a big warning that the connection was not secure! Very strange, Google uses https for gMail and other mobile browsers including WebKit and Opera do show the page as secure. I decided to press on, and entered my credentials. Other than the initial message that the page was unencrypted, gMail worked OK. Switching to Yahoo Mobile Mail, it worked most of the time although I got a couple more “Connection Refused…” messages. A lot of other sites including Engadget and MSNBC worked without any problems.<\/p>\n

However, trying to follow a link to a page on TechCrunch’s full site failed completely. OpenWeb gave a strange error to the effect that the page I requested “exists but could not be loaded” and that the issue is being “investigated” . I also got “Page can not be displayed” trying to load the full web version of HowardForums. Overall I’d say I had trouble with about 10% of the pages I tried to visit with OpenWeb<\/strong>, a considerably higher error rate than with Opera Mini, Mowser, Skweezer or Google GWT. I’ll admit that I rarely use the Obigo browser for anything other than downloading content, mostly applications, so it’s possible some of the errors may been with with the browser rather than the transcoder.<\/p>\n

Other impressions of OpenWeb were that it works like a typical transcoder, reformating pages into a single column. Cookies seem to be supported and web forms using both get and post worked<\/strong> (earlier versions of OpenWeb reportedly turned Posts to Gets which seems to be fixed now). OpenWeb doesn’t fold content to hide navigation links like Opera mini or Google GWT. Pages are split at around 30 KB which is probably about the maximum Obigo can handle so that’s good. OpenWeb seems to retain quite a bit of CSS formating including borders, background colors and floats on images. Browsing through OpenWeb seemed slow, there were often delays of 30 seconds or so before a page started loading, definitely not the normally snappy response I expect on Sprint’s 3G EVDO network. I also don’t like that OpenWeb reduces all images to a maximum width of around 120 px, considerably smaller than the A920’s full screen width of 176 px.<\/p>\n

While I imagine that Sprint and OpenWave executives think they are improving the mobile web experience with this transcoder, I find that it worsens my experience. I’m put off by it’s slowness, loss of the User Agent on even a few sites and the high level of errors. But the worst part is that it’s being imposed on me without asking and with no way to turn it off or even visit an untranscoded page when an error occurs. Sprint is bleeding customers and it’s stock price is in the toilet, OpenWeb in it’s current format is likely to drive even more customers away. Sprint needs to make OpenWeb optional and OpenWave needs to add a “View in HTML” link to each transcoded page like Google does. If Sprint really<\/strong> wants to improve the browsing experience for users they should partner with Opera<\/strong> to bundle Opera Mini with all their new phones and offer it has a free download from their portal homepage!<\/p>\n","protected":false},"excerpt":{"rendered":"

Last week Opera released a minor upgrade to the Opera Mini browser. I like to follow the latest releases so I downloaded it to all my phones from mini.opera.com. I used each phone’s built-in browser so Opera could detect the phone model and send the optimal version of Opera Mini. All went well until I tried to upgrade my Samsung A920. I got a message “Your phone model could not be detected” This seemed strange as Opera had recognized the … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":13953,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[19],"tags":[],"_links":{"self":[{"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/posts\/510"}],"collection":[{"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/comments?post=510"}],"version-history":[{"count":0,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/posts\/510\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/media\/13953"}],"wp:attachment":[{"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/media?parent=510"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/categories?post=510"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wapreview.com\/wp-json\/wp\/v2\/tags?post=510"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}