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

Ref Bryan's point about how proxies typically handle such things, the
problem we are trying to work around is that each of those approaches is
an exposure to the "same domain" problem, i.e. the browser thinks that
the proxy is all the sites it has ever visited since the domain portion
is constant. This leads to problems with scripts and cookies.

If people are not happy using subdomains how about using the port to
achieve this? I'm not really comfortable specifying a specific technique
for this, btw, I just want to show that there is a way of not defeating
the same origin policy attached to these things and making that a
mandatory compliance condition for link rewriting.

Jo


> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Francois Daoust
> Sent: 19 March 2009 17:31
> To: Sullivan, Bryan
> Cc: Robert Finean; Public MWBP
> Subject: Re: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> 
> Argh. Well. Good point.
> 
> [I should have remembered, there's a very similar divergence in
> browsers
> implementations of the checks against domain names with wild cards in
> SSL certificates, we stumbled upon the issue while implementing the
> mobileOK Checker]
> 
> Francois.
> 
> 
> Sullivan, Bryan wrote:
> > Hi Francois,
> > Per the source of all reliable knowledge
> (http://en.wikipedia.org/wiki/Wildcard_DNS_record), reliance upon DNS
> wildcards seems problematic.
> >
> > Best regards,
> > Bryan Sullivan | AT&T
> > -----Original Message-----
> > From: Francois Daoust [mailto:fd@w3.org]
> > Sent: Thursday, March 19, 2009 10:07 AM
> > To: Sullivan, Bryan
> > Cc: Robert Finean; Public MWBP
> > Subject: Re: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> >
> > Just chiming in, I do not know whether that's reasonable to do it or
> > not, but I think it's possible to define a DNS record of the form
> > *.example.org to target a server, removing the impossible need to
> have
> > one DNS record per existing domain name around.
> >
> > Francois.
> >
> >
> > Sullivan, Bryan wrote:
> >> Hi Rob,
> >> The concern is based upon the a domain-based approach involving the
> assignment of subdomains through DNS. If the set of domains to be
> rewritten is fairly static (e.g. only a few changes per day) then DNS
> can handle it, although it is an overhead on someone (or some system)
> to update DNS records and for the records to be distributed through
the
> DNS system as requested.
> >>
> >> An alternate approach is to use URL path tokens associated with the
> specific domains being rewritten, e.g. for
"http://origdomain.com/path"
> one of the methods:
> >> "http://ctproxy.com/rewriter/origdomain.com/path"
> >> "http://ctproxy.com/rewriter/f8w7yf87ch/path" (where "f8w7yf87ch"
is
> some token that the CT proxy assigns to the original domain)
> >> "http://ctproxy.com/rewriter?origuri=http://origdomain.com/path"
> (with URI escaping as needed)
> >>
> >> I'm sure there are many more such approaches.
> >>
> >> These approaches do not impact DNS, and thus are better suited for
> cases in which the CT proxy is not pre-configured to support rewriting
> for an arbitrary web site ala this sequence:
> >> (1) User browses to a site through the CT proxy
> >> (2) The site returns content with links to other sites, which are
> rewritten by the CT proxy to ensure the requests flow through it
> >>
> >> The sites in (2) may not already be setup for link rewriting at the
> CT proxy. It would be a very significant overhead on the DNS system to
> issue DNS update requests for such dynamically configured sites.
> >>
> >> Is that clearer?
> >>
> >> Best regards,
> >> Bryan Sullivan | AT&T
> >>
> >> -----Original Message-----
> >> From: Robert Finean [mailto:Rob.Finean@openwave.com]
> >> Sent: Thursday, March 19, 2009 7:26 AM
> >> To: Sullivan, Bryan
> >> Cc: Public MWBP
> >> Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> >>
> >> Hi Bryan,
> >>
> >> I don't understand this rationale:
> >>
> >> <<
> >> 2) PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
> >> transformation is permitted, providing that content domain origin
> >> distinctions are preserved by the proxy.
> >> -1 : Rationale is that scalability and basic ability to dynamically
> >> extend the link rewriting support to new sites will prevent a
> subdomain
> >> approach from being feasible. Link rewriters that I have worked
with
> use
> >> URL path tokens associated with the original URI, which is scalable
> >> since there is no dependency upon DNS.
> >>
> >> Can you explain please (maybe an example)?
> >>
> >> thanks,
> >>
> >> ROb
> >>
> >>
> >

Received on Thursday, 19 March 2009 19:55:24 UTC