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

Thanks Bryan

> "CT Proxies SHALL ensure that link rewriting of web resources has no
> impact upon same-domain restrictions or functionality of basic web
> features, e.g. cookies and scripting".

I agree that is the overall objective, but the problem is that I don't see it as a testable statement. Any ideas on how to make it testable?

Jo

> -----Original Message-----
> From: Sullivan, Bryan [mailto:BS3131@att.com]
> Sent: 19 March 2009 21:13
> 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,
> I can't be sure this covers it, but here's a go:
> 
> "CT Proxies SHALL ensure that link rewriting of web resources has no
> impact upon same-domain restrictions or functionality of basic web
> features, e.g. cookies and scripting".
> 
> Overall though if we are also talking about non-secure HTTP link
> rewriting, the typical network-based proxy approach (either configured
> or transparent) will avoid all the link rewriting issues to start with.
> It is quite common (at least in PLMN's) for there to be some proxy in
> the path. Only when a resource includes HTTPS links would there be a
> possible need to rewrite links (and then bring in all the caveats).
> Note also that devices designed to not use network proxies (at least
> explicitly) usually have more full-featured browsers.
> 
> Of course in the case of the value-added CT proxy provider out there on
> the internet, link rewriting as a means to become a "sticky" proxy may
> be necessary.
> 
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi]
> Sent: Thursday, March 19, 2009 1:53 PM
> To: Sullivan, Bryan; Francois Daoust
> Cc: Robert Finean; Public MWBP
> Subject: 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 Friday, 20 March 2009 08:22:32 UTC