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

 > I'm jumping straight to the conclusion because the rest is French
 > cuisine, you know, a perfect balance between spices, herbs, meat, wine
 > and cheese, so I don't see anything to add.

High praise indeed ;-)


 > Without context, the exception-to-the-rule looks weird. Or rather it
 > makes me think I missed a bit of context. Is the exception only
 > triggered by the case when a Content Provider agrees to the
 > "interception of" HTTPS and thus also needs to agree on links rewriting,
 > or is there something else?
 >
 > I would agree in the first case, and would like to know what I missed in
 > the second case.


Yes, that's right. In order to rewrite HTTPS links you have to allow 
rewriting links in general. I haven't actually given this a lot of 
thought, but I assume that if you are rewriting HTTPS links you probably 
have to rewrite the others too.

FWIW by stating that Google etc. (user choice) proxies are out of scope 
we deny them the undoubted benefit :-) of choosing to claim conformance 
and this provision makes it impossible anyway. I think that this is the 
only place where the conformance breaks down - would it be a good idea 
to extend the scope and make a carve-out in this case to allow proxies 
that can't work any other way to claim conformance, subject to the 
security considerations? How would we define "can't work in any other 
way"? Would it be good enough to water this down to a SHOULD NOT?

In any case, would someone like to volunteer to write the security 
considerations?

Jo

On 09/03/2009 21:41, Francois Daoust wrote:
> Hi Jo,
> 
> Many thanks for this summary of summaries.
> 
> I'm jumping straight to the conclusion because the rest is French 
> cuisine, you know, a perfect balance between spices, herbs, meat, wine 
> and cheese, so I don't see anything to add.
> 
> Jo Rabin wrote:
> [...]
>>
>> 4. Conclusions and Proposed Resolutions
>>
>> 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 to the proposed resolution and to the arguments that led to it.
> 
> 
>>
>> b. PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links 
>> without explicit prior agreement from the Content Provider
> 
> Without context, the exception-to-the-rule looks weird. Or rather it 
> makes me think I missed a bit of context. Is the exception only 
> triggered by the case when a Content Provider agrees to the 
> "interception of" HTTPS and thus also needs to agree on links rewriting, 
> or is there something else?
> 
> I would agree in the first case, and would like to know what I missed in 
> the second case.
> 
> 
>>
>> 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
> 
> +1. The proposed resolution is indeed to be read in the scope of the 
> Content Transformation guidelines about network-deployed content 
> transformation proxies. I don't think we should extend this scope.
> 
> 
> I also agree with the non-normative security consideration note on links 
> rewriting:
>> Either way it would be worthwhile making a note as to the security 
>> issues discussed above in a non-normative way.
> 
> 
> Francois.

Received on Tuesday, 10 March 2009 10:41:48 UTC