Re: [wmlprogramming] Verizon, guidelines

On 23 Dec 2008, at 11:37, Luca Passani wrote:

> It's very hard to discuss with you when you are hyperactive in  
> misunderstanding what I wrote. When I say that CTG should rule out  
> any possibility of UA spoofing, the answer is no. When I make an  
> example of how UA spoofing will bring to catastrophic user  
> experience and will infringe on the rights of the content owner,  
> your answer is "the UA cannot be spoofed".
> How can we proceed in the discussion in these conditions?

Your argument is predicated on transcoders aggressively transcoding  
and UA spoofing, as the Vodafone/Novarra installation did. My point is  
that a CTG-compliant transcoder won't do this in the first place, and  
that the situations you outline as being problematic will not occur.

>>>> No, it wouldn't.  Transcoder vendor just needs to claim that this  
>>>> is what the user wants. This has also been demonstrated in  
>>>> practice by Verizon.

Verizon was nothing to do with user choice; it was a false claim that  
URL pattern matching was an endorsed technique.

Transcoders vendors don't "just need to claim that this is what the  
user wants". The wording of CTG is quite specific here: users must  
"specifically request a restructured desktop experience" (i.e. not be  
presumed to want it), and as Jo has pointed out, transcoders must  
assume that by default users get the representation intended by the  
server. CTG is also specific about how preferences are maintained -  
site by site and user by user.

This is all very specific, and rules out the case you're referring to.

>> Caching is an example of somewhere where exactly this has been  
>> happening for years. And caches have been configured over- 
>> aggressively in the past, causing problems.
> There is a few *big* differences here:
> - Once the no-cache headers have been added, the caching proxy will  
> not impair the ability of a web application to recognize the  
> requesting client and work properly.
> - Caching has not been introduced abusively by one company from one  
> day to the next with the attached message "screw you" for the rest  
> of the ecosystem.

Actually, in the mid-90s I remember there were issues with web proxy  
caches aggressively caching, which caused problems for web developers  
and meant we had to add HTTP headers. The situation feels analogous to  
me.

>>>>> OK, but here CTG and you are in agreement (and I think Jo has  
>>>>> pointed out specific sections of CTG which state this).
> No. We are not in agreement. In my view, no action whatsoever should  
> be required of mobile developers in order for them to protect their  
> applications. This is a *BIG* difference. The rest is cosmetic.

This is where we agree. Prohibiting transformation is different from  
protecting an application. By default CTG-conformant transcoders will  
give unfettered access to mobile apps, without content providers or  
developers doing any work.

It's only if you want to prohibit transformation completely in all  
circumstances that you need to do more... in the same way that you  
have to do more to prohibit caching completely.

>> And given that it can happen, how can it happen without UA spoofing?
> The Manifesto way, for example, which is being adopted in practice  
> by loads of installations around the planet (Sprint in the US and  
> Voda in South Africa, just to mention two off the top of my head).
> Send the request with original headers. If the response is not  
> mobile, then transcoders are allowed to re-issue with a spoofed set  
> of headers to get clean full-web HTML.

So there *are* circumstances, in both CTG and Manifesto, where  
transcoders are allowed to spoof headers. In Manifesto, it's when a  
first request has shown the site isn't mobile-aware. In CTG it's when  
the user asks for it.

I note that this setup will cause problems, as Eduardo and I think  
you, have pointed out. Sites which tie transactions to GET requests  
(they shouldn't, but they exist) will be affected by this sort of  
double-hit.

>>>> Me neither, but I think CTG achieves this.
> No. It doesn't. Where the Manifesto has been adopted, problems have  
> been solved. Where CTG has been adopted (Verizon), confusion and  
> frustration has been the result.

CTG has never been adopted. It isn't complete and is clearly marked as  
such.

> But there is more. Transcoder vendors who adopted the Manifesto have  
> been very responsive to developer issues and worked together with  
> developers to fix them in actual installations. Vendors who did not  
> sign, on the other hand, tried to hide behind their customers  
> letting them take the wrap for their wrong doing.

Really? I saw Vodafone/Novarra whitelist .mobi and m. sites sharpish,  
and Verizon update their documentation when it was pointed out that it  
was erroneous. Responding to developers isn't the sole province of  
Manifesto-compliant vendors.

>>> Well, I did point out in my post that exactly this was happening  
>>> and that JavaScript was being messed up by Vodafone - who are a  
>>> pretty large ISP. I also referenced the Manifesto and CT  
>>> guidelines in my post; so I think I've represented the dangers  
>>> accurately ("this is happening. It's likely to happen more."). One  
>>> of the responders noted that they'd seen the problem already and  
>>> were working around it by messing with their JavaScript, the other  
>>> suggested no-transform as the answer.
> well, but Vodafone is a mobile ISP, i.e. not a major wireline ISP. A  
> real DSL ISP would not make such sloppy mistakes or they would be  
> flooded by customer calls.

I think you're slightly out of touch if you think that a mobile ISP  
can't be a major ISP, or isn't "real" in some way.

Tom

--
Future Platforms Ltd
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
company: www.futureplatforms.com
personal: tomhume.org

Received on Tuesday, 23 December 2008 12:11:11 UTC