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

 > -1 because explicit prior agreement from 50M long-tail
 > Content Providers won't happen.

this is not about happening or not happening. This is about whether 
breaking HTTPS can happen in W3C's name or not.

Luca



Robert Finean wrote:
>> 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
>
>
>
>
>

Received on Tuesday, 10 March 2009 17:01:37 UTC