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

Hi Jo,
Given an understanding of the cases in which the features will be broken, I'm sure that test cases (e.g. using server code and javascript to automate the tests) could validate compliance. There could be some easy examples, and others only discovered through adhoc testing of prototypes. 

The latter can uncover weaknesses with existing services, which can then be analyzed in detail as to why they are weaknesses and whether they are systemic issues. Tracking the number of such adhoc issues might also provide a useful metric for the robustness of the implementation.

I don't have any more specific suggestions at this point.
 
Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: Friday, March 20, 2009 1:22 AM
To: Sullivan, Bryan; Francois Daoust
Cc: Robert Finean; Public MWBP
Subject: 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 15:09:01 UTC