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

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

From: Tom Hume <tom.hume@futureplatforms.com>
Date: Fri, 20 Mar 2009 09:59:27 +0000
Message-Id: <6D254F80-976C-431B-B0BB-D512F9010373@futureplatforms.com>
To: Public MWBP <public-bpwg@w3.org>

On 19 Mar 2009, at 22:49, Sean Patterson wrote:

> 2) PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links
> without explicit prior agreement from the Content Provider
> -1.  It's not practical to get explicit permission from content
> providers to do transformations.  It is too much effort and doesn't
> scale.

I can see how this is difficult. But can it therefore be considered  
best practice to not get such permission?

> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
> transformation is permitted, providing that content domain origin
> distinctions are preserved by the proxy.
> -1.  I don't really think this would work.  For a CT proxy that is
> rewriting URLs so that traffic gets directed to it, the URIs need to
> point to the proxy or it won't work.

You could imagine a set of configured subdomains (e.g.  
tescos.transformingproxy.com, safeways.transformingproxy.com) that  
might achieve the same effect.

> Another thing to keep in mind in regard to general link rewriting: CT
> proxies that I am familiar with process the scripts and cookies
> themselves and don't pass them down to the user's browser.  So even if
> links are rewritten to all have the same domain, the security risk is
> mitigated significantly because no scripts get passed down to the  
> client
> that can try to illegitimately access frames, iframes, or cookies from
> different domains.

If this is the case and contributes to the safety of such proxies,  
should this behaviour be considered a best practice itself?

--
Future Platforms
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
work: www.futureplatforms.com
play: tomhume.org
Received on Friday, 20 March 2009 10:00:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC