W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

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

From: Robert Finean <Rob.Finean@openwave.com>
Date: Mon, 16 Mar 2009 11:40:55 -0000
Message-ID: <7F652B9B6A93184AB38BBCF677E7287A059E251F@bfs-exch-prd1.myopwv.com>
To: "Francois Daoust" <fd@w3.org>
Cc: "Public MWBP" <public-bpwg@w3.org>
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

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

 - 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



-----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
> 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
> 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.

Received on Monday, 16 March 2009 11:42:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC