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

I find that I am in agreement with Rob on these issues:

1) PROPOSED RESOLUTION: Link rewriting is a form of transformation and
at a minimum is subject to the same limitations as other forms of
transformation

+1.  It is a transformation.

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.

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.

3) PROPOSED RESOLUTION: Interception of HTTPS is not permissible without
consent from the user on a case by case basis

+1.  As mentioned, this is already in the document.  I agree with
Brian's point that it needs to be possible to keep persistent user
preferences.  Otherwise the user experience isn't good.

4) PROPOSED RESOLUTION: Interception of HTTPS is not permissible without
explicit prior agreement from the Content Provider

-1.  As with general link rewriting, it isn't practical to get explicit
prior agreement with enough sites to make the feature useful.  There is
the option of no-transform for sites that don't want HTTPS links
rewritten.  I know there has been some discussion of the fact that a
site doesn't always have control over where its HTTPS requests come
from--the user could type in an HTTPS URI or there could be an HTTPS
link from another site.  However, I think it was Sean Owen that pointed
out that, from a practical standpoint, the first HTTPS request is almost
always for a login page.  If the site makes the login page no-transform,
then there really isn't any harm from a security standpoint.  (The CT
proxy transformed the request for the login page and that's it.  The
user will be redirected by the proxy to the untransformed login page.)

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.

Sean



> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Jo Rabin
> Sent: Thursday, March 19, 2009 4:25 AM
> To: Public MWBP
> Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> 
> I'd like to push this subject along in preparation for the F2F.
> 
> To re-state the points:
> 
> 1) PROPOSED RESOLUTION: Link rewriting is a form of transformation and
> at a minimum is subject to the same limitations as other forms of
> transformation
> 
> So far we have consensus on this.
> 
> 2) PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links
> without explicit prior agreement from the Content Provider
> 
> Rob makes the (to my mind reasonable) point that this makes a number
of
> important operations much more difficult, if not impossible to do. The
> point remains, however, that link rewriting is dangerous primarily
> because of the assumptions about "same domain" that browsers make. I
> think we need clear cut conformance statement about how to do this. I
> also agree with the point that making the distinction between "search"
> proxies and Inline proxies is too complicated and I think that if the
> perceived vulnerabilities are addressed then there is no need for that
> distinction.
> 
> So, I wonder if it would be sufficient for us to say
> 
> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
> transformation is permitted, providing that content domain origin
> distinctions are preserved by the proxy.
> 
> e.g. when accessing content derived from example1.mobi and
> example2.mobi, from the browser perspective these are presented as
> distinct domains e.g. xyz.transform.com and wxy.transform.com.
> 
> I think we also need to be clear what this means in terms of IP
> addressing too.
> 
> 3) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
without
> consent from the user on a case by case basis
> 
> This is already part of the spec and doesn't seem contentious (aside
> from perhaps needing to be clear whether we think that it's
permissible
> to allow the user to express a persistent preference for that domain,
> site or in general).
> 
> 4) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
without
> explicit prior agreement from the Content Provider
> 
> I take the point that it's impractical to gain agreement from "the
long
> tail". There is clearly room for a broader vocabulary of preference
> expression on the part of Content Providers. However, such a
vocabulary
> does not exist today.
> 
> Either way, I believe that absent any clear indication from a content
> provider that they permit rewriting of HTTPS links it is unsafe and
> can't be described as "best practice" to do so.
> 
> It remains an open question as to what explicit prior agreement
consists
> of absent any signalling mechanism. There is an associated conformance
> question on this point.
> 
> Jo
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
> On
> > Behalf Of Jo Rabin
> > Sent: 11 March 2009 09:40
> > To: Robert Finean
> > Cc: Public MWBP
> > Subject: Re: ACTION-902 Summarise and prepare proposed resolutions
on
> > HTTPS link rewriting.
> >
> > Thanks Rob
> >
> > Comments in-line ...
> >
> > Jo
> >
> > On 10/03/2009 16:16, Robert Finean wrote:
> > >> Jo Rabin wrote:
> > >>> a. PROPOSED RESOLUTION: Link rewriting is a form of
transformation
> > > and
> > >>> at a minimum is subject to the same limitations as other forms
of
> > >>> transformation
> > >
> > > +1 from me too
> > >
> > >
> > >>> b. PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite
links
> > >>> without explicit prior agreement from the Content Provider
> > >
> > > -1 because explicit prior agreement from 50M long-tail Content
> > Providers
> > > won't happen. Link rewriting (HTTP and/or HTTPS) is part of
> > adaptation
> > > because:
> > >  - URIs must be invented to represent browsing actions within a
> > single
> > > Content-Provider's URI (eg view a different sub-page; trigger a
> > > javascript event; move from one part of a form to another where a
> > form
> > > is split across sub-pages)
> > >  - Tokenising URIs is a very effective data-compression trick for
> > > adapted content that dramatically improves end-user usability
> > >
> > > There are security implications that need to be laid out and
> > addressed.
> > > Those security implications are the vital issue here, not link
> > > rewriting. Even flattening a frameset into one page for display on
> an
> > > XHTML/MP phone can raise these security questions so link
rewriting
> > > isn't the crux of the matter.
> > >
> > That seems fair enough. What I was trying to avoid, and the crucial
> > point to my mind, is then specifying how the security implications
can
> > be fixed up and how one could assess compliance with them. Ref your
> > earlier work on this [1], under ACTION-893, you make a number of
> > excellent suggestions. However, I think that if compliance with the
> > security provisions attached to this can only be achieved through
> > software and physical audit then we have a problem of normativeness,
> > unless we are going to build such an audit into the compliance
> > provisions. While I'd prefer to avoid this, I wouldn't personally
rule
> > it out. It's much preferable for compliance to be assessed by
"opaque
> > box" testing. I also think that Eduardo's comment at [2] 1) about
the
> > vulnerabilities shared by CT proxies and browsers is particularly
> > material to this point.
> >
> > [1]
http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0023.html
> > [2]
http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0045.html
> >
> > Incidentally, I am aware of an inconsistency between the "opaque
box"
> > normativeness and the carve out in my PROPOSED RESOLUTION relating
to
> > explicit prior consent from the CP, which would be hard to assess by
> > such techniques.
> >
> > > I'm uncomfortable about one stinging rule for mobile networks
> > > (in-network adaptation) vs out-of-scope for search partners and
> > > distributed browsers (hosted adaptation).
> > >
> >
> > I'm uncomfortable with that too. I agree with the point about search
> > related transformation, but distributed browsers (which are a
> different
> > case, to my mind) have always been out of scope.
> >
> > >
> > >>> c. PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> > >>> without  explicit prior agreement from the Content Provider and
> > >>> consent from the user on a case by case basis
> > >
> > > I'd suggest this resolution is split into its 2 clauses:
> > >
> > >  c1. PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> > >  without explicit prior agreement from the Content Provider
> > >
> > > -1 because explicit prior agreement from even 10K long-tail
Content
> > > Providers that use HTTPS to log in won't happen. Sean gave a few
> > > examples that are just the tip of this iceberg.
> >
> > I think that's unfortunate but unavoidable. If I get Rigo's argument
> > correctly, it is that when you put stuff on the Web you must expect
> Web
> > like stuff to happen. So it seems to me that in the case of
"general,
> > non HTTPS, transformation", a content provider must expect that
normal
> > Web paradigms will apply, including selective display etc. etc. etc.
> as
> > discussed at length on this list. By the same argument, when you
make
> > content available under HTTPS your expectation is that there will be
> an
> > end-to-end connection, and so the burden of contradicting the
> > expectation falls upon those who wish to intercept the connections.
> >
> > Please note that I am invoking Rigo's point in a way that he may not
> > have intended it so it would be prudent to ask him to opine on
whether
> > the argument is sound or not.
> >
> > >
> > >  c2. PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> > >  without consent from the user on a case by case basis
> > >
> > > +1 to this clause
> > >
> > >
> >
>

Received on Thursday, 19 March 2009 22:50:29 UTC