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

> Jo Rabin wrote:
>> a. PROPOSED RESOLUTION: Link rewriting is a form of transformation
and 
>> at a minimum is subject to the same limitations as other forms of 
>> transformation

+1 from me too


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

I'm uncomfortable about one stinging rule for mobile networks
(in-network adaptation) vs out-of-scope for search partners and
distributed browsers (hosted adaptation).


>> c. PROPOSED RESOLUTION: Interception of HTTPS is not permissible 
>> without  explicit prior agreement from the Content Provider and 
>> consent from the user on a case by case basis

I'd suggest this resolution is split into its 2 clauses:

 c1. PROPOSED RESOLUTION: Interception of HTTPS is not permissible 
 without explicit prior agreement from the Content Provider

-1 because explicit prior agreement from even 10K long-tail Content
Providers that use HTTPS to log in won't happen. Sean gave a few
examples that are just the tip of this iceberg. 

 c2. PROPOSED RESOLUTION: Interception of HTTPS is not permissible 
 without consent from the user on a case by case basis

+1 to this clause