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 Thursday, 12 March 2009 15:13:55 UTC