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

Fair enough, I'm afraid I am no expert on this topic, and did not look carefully enough at the source of all knowledge you cited earlier which I now see says that the same domain policy includes (in most browsers) the port number.

http://en.wikipedia.org/wiki/Same_origin_policy

To be clear we are not referring to HTTPS link rewriting we are talking about ALL link rewriting here. If we can't find a way of writing a compliance statement that shows that appropriate precautions have been taken in respect of cookies and scripts then we will have to rule it out I think.

Is it sufficient to say that forwarded cookies and scripts must not to contravene same origin hygiene rules. Are these the only two issues that are relevant? What would such a statement look like, more formally put?

Jo


> -----Original Message-----
> From: Sullivan, Bryan [mailto:BS3131@att.com]
> Sent: 19 March 2009 20:06
> To: Jo Rabin; Francois Daoust
> Cc: Robert Finean; Public MWBP
> Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> 
> Hi Jo,
> Do you mean a TCP port? That has the same problem, i.e. the hostname is
> in the CT proxy domain, so there is no difference re cookies.
> 
> The issues with same origin, cookies, and scripts etc are examples of
> why I think that HTTPS link rewriting is problematic in general; you
> have to chase so many possible gotchas that it becomes a fragile
> endeavour.
> 
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi]
> Sent: Thursday, March 19, 2009 12:55 PM
> To: Francois Daoust; Sullivan, Bryan
> Cc: Robert Finean; Public MWBP
> Subject: 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 20:54:06 UTC