Scarecrow - 8:06 pm on Mar 8, 2011 (gmt 0)
Google Wireless Transcoder is now more frequently referred to by its unofficial name, "Google Mobilizer." Several Apple web-browser apps use this Google tool, and refer to it in their browser specs as a "compression" feature. What happens when this compression is enabled in that browser is that the page is sent to Mobilizer, and Google sends it back to the mobile device after rewriting all the links on the page. This rewrite keeps the user locked into Mobilizer as they follow links on the pages they surf.
The problem I have with Mobilizer is that it strips out important functionality from the original page. For example, I use a POST input form, and it appears to me, after a lot of research, that Mobilizer disables POST input forms on all pages that use them. I believe that this is because if they let the POST input form through unaltered, the user would drop out of Mobilizer after submitting the form. And it would be a lot of trouble for Google to capture user-submitted POST information, as compared to GET. The GET forms go through okay.
Here is the user-agent for Mobilizer; this came from 126.96.36.199 but Google also uses other IP addresses for this:
Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Wireless Transcoder) Version/3.1 Safari/525.13
When I detect this on one dynamic page I use, I intercept the interceptor with a decoy page, and explain to the user that if they want to use my site on their device, they either have to turn of compression, or they have to start using our SSL input pages.
Google offers a tool that allows you to see how any page will look after Mobilizer processing: [google.com...]