- From: Francois Daoust <fd@w3.org>
- Date: Thu, 12 Mar 2009 15:30:31 +0100
- To: Jo Rabin <jrabin@mtld.mobi>
- CC: Public MWBP <public-bpwg@w3.org>
Jo Rabin wrote: [...] > 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? I don't think watering this down to a SHOULD NOT is a good solution. One (relatively) simple way to allow linked-mode transforming proxies to still be able to conform to the specification is to create an additional class of Transformation Deployment product (see [1] in the latest draft). This new class or product would be exempted from the "do not rewrite links" rule. Classes of product could be: - In-network Transformation Deployment - Er... Endpoint Transformation Deployment? Linked-mode Transformation Deployment? I'm personally in favor of that (provided we resolve to adopt the "do not rewrite links" rule, that is). Obviously, if we really want this new class of product to conform to a security considerations part, we would need to have this security considerations part defined as normative. I'm not convinced that we need to require that, though. I more and more have the feeling that security considerations are orthogonal to the Content Transformation guidelines. We should alert these deployments about security issues, but I don't think we need to cover them all with normative guidelines and require they be respected. Francois. [1] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-classes-of-product > > 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 Thursday, 12 March 2009 14:31:12 UTC