Re: ACTION-902 Summarise and prepare proposed resolutions on HTTPS link rewriting.

Noted. But then what about going for a review of CTG that removes the 
possiblity of spoofing HTTP headers until the transcoder is sure that no 
mobile content is in place? this just to be able to get away with all 
kind of reformatting tricks on web-only content one second later.

That would be a reasonable compromise for everyone except those who want 
to extort web content out of sites that may have a mobile version ready.

at that point, there would be no need for standardized heuristics, be it 
specifying them, adhering to them or revealing the recipe for your 
secret sauce to the competition.

Luca

Robert Finean ha scritto:
> Hi Luca,
>
> To be clear I'm talking about the need to make the transcoder's
> "virtual-browser" the origin domain only when it has been established
> beyond reasonable doubt that the content (requested for the mobile's
> User-Agent) isn't suitable for this User-Agent and that it needs
> adaptation. I totally agree that changing origin domain is adaptation
> and therefore MUST NOT be done to content that's already
> mobile-friendly.
>
> Thanks,
>
> Rob
>
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Luca Passani
> Sent: Mon 16 March 2009 13:58
> To: Public MWBP
> Subject: Re: ACTION-902 Summarise and prepare proposed resolutions on
> HTTPS link rewriting.
>
> Roberts,
>
> I think that, from an engineering perspective, your comments make sense.
>
> On a more general level, when the big picture of the problem is 
> considered, they do not. Here is my view (with my Manifesto editor hat):
>
> - transcoder vendors have shown how skillful they are in driving a train
>
> through any loophole they find in whatever specs that serves their 
> purpose. For this reason, the only sensible stance CTG should take is to
>
> force transcoders to err on the side of NOT reformatting whenever in the
>
> presence of content which might already be fit for mobile (Novarra has 
> publicly declared multiple times their intention to transcode 
> already-mobile-optimised content too).
>
> I think the rules should still say MUST NOT. Actual implementations may 
> take the freedom to override those rules when they feel their superior 
> technology has made it clear that it's no a mobile site they are dealing
>
> with. "Should not" is too weak.
>
> Alternatively, you can re-think CTG and take an approach like the one in
>
> the Manifesto. Do not spoof the UA or any other HTTP header in any way. 
> If the response is full-web, and not fit for mobile beyond reasonable 
> doubt, a transcoder can re-issue a spoofed request to get a clean 
> web-only response and take off with transcoding from there. At that 
> point, a transcoder can apply all of its dirty tricks to achieve 
> best-effort transcoding, without interfering with the work of those who 
> have mobile content in place (and without caring too much about these 
> heuristics).
>
> This idea was discarded by CTWG because of the fact that multiple GETs 
> may not yeld the same result, but this argument is totally bogus when 
> applied to a technology which is doing best-effort adaptation in the 
> first place.
>
> Luca
>
> Robert Finean ha scritto:
>   
>> Origin domain is changed during adaptation for good reasons and it
>>     
> does
>   
>> seem absurd to give network operators a MUST NOT for this but
>>     
> everybody
>   
>> else an out-of-scope. Just to be 100% clear this is changing origin
>> domain solely to adapt long-tail content that won't work on the phone
>> otherwise.
>>
>> All use-cases can't work with this MUST NOT. For example:
>>
>>  - A good number of pre-2006 handsets truncate URIs at 256 chars. Many
>> long-tail websites use URIs longer than this and appending even more
>> information using specific query-string params makes matters worse
>> still.
>>
>>  - Any frameset MUST be flattened for XHTML/MP phones: the frames will
>> have their URIs disappear completely from the phone's perspective.
>>
>>  - Tokenisation of URIs as a compression technique results in
>> much-improved user-experience on phones with limited heap RAM,
>>     
> including
>   
>> the most popular phones on the planet.
>>
>>
>> In summary, I'm still unclear what the root concern is and I doubt if
>> it's feasible to make all use-cases work with this restriction. Hence
>>     
> I
>   
>> doubt if you would get any compliant implementations of the candidate
>> rec.
>>
>> Thanks,
>>
>> Rob
>>
>> -----Original Message-----
>> From: Francois Daoust [mailto:fd@w3.org] 
>> Sent: Thu 12 March 2009 15:13
>> To: Robert Finean
>> Cc: Jo Rabin; Public MWBP
>> Subject: Re: ACTION-902 Summarise and prepare proposed resolutions on
>> HTTPS link rewriting.
>>
>> Robert Finean wrote:
>>   
>>     
>>>>> b. PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links 
>>>>> without explicit prior agreement from the Content Provider
>>>>>         
>>>>>           
>>> -1 because explicit prior agreement from 50M long-tail Content
>>>     
>>>       
>> Providers
>>   
>>     
>>> won't happen. Link rewriting (HTTP and/or HTTPS) is part of
>>>       
> adaptation
>   
>>> because:
>>>  - URIs must be invented to represent browsing actions within a
>>>       
> single
>   
>>> Content-Provider's URI (eg view a different sub-page; trigger a
>>> javascript event; move from one part of a form to another where a
>>>       
> form
>   
>>> is split across sub-pages)
>>>  - Tokenising URIs is a very effective data-compression trick for
>>> adapted content that dramatically improves end-user usability
>>>
>>> There are security implications that need to be laid out and
>>>     
>>>       
>> addressed.
>>   
>>     
>>> Those security implications are the vital issue here, not link
>>> rewriting. Even flattening a frameset into one page for display on an
>>> XHTML/MP phone can raise these security questions so link rewriting
>>> isn't the crux of the matter.
>>>     
>>>       
>> The crux of the problem is indeed not links rewriting per se, it's the
>>     
>
>   
>> change of origin.
>>
>> The proposed resolution could rather read:
>>
>> PROPOSED RESOLUTION: In-network proxies MUST NOT change links origin 
>> without explicit prior agreement from the Content Provider (where 
>> "origin" is defined as the domain name, the scheme and the TCP port of
>>     
>
>   
>> the link)
>>
>> Can all use cases be done without changing the origin? I think most
>>     
> can,
>   
>> for example using specific query string parameters in the request that
>>     
>
>   
>> the CT-proxy reacts to. Is it a clean solution though? I'm not sure. 
>> Besides, I don't think it covers the frameset case, but then
>>     
> flattening 
>   
>> frames with different origins is probably not a good idea.
>>
>> I understand tokenisation of URIs decreases size. That's not enough of
>>     
> a
>   
>> use case to allow a change of origin, IMHO.
>>
>> Francois.
>>     
>
>

Received on Monday, 16 March 2009 15:22:54 UTC