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

Hi Jo, 
Comments on the proposed resolutions:

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

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.

3) PROPOSED RESOLUTION: Interception of HTTPS is not permissible without consent from the user on a case by case basis
+1 with the caveat: this must be possible to express as a static preference, i.e. either the W3C should remain silent (not explicitly prohibit static preferences) or state an optional requirement (CT proxies MAY use static user preferences for link rewriting). As a service provider we must address the key issues with mandating case-by-case user consent: (a) too many prompts is a user experience killer (users will not use such a service often; (b) user prompts significantly increase service complexity and traffic. 

4) PROPOSED RESOLUTION: Interception of HTTPS is not permissible without explicit prior agreement from the Content Provider
+1 with the caveat (obvious?): regardless of how obtained, such agreement must not require case-by-case approval, i.e. it must be possible to express as a static preference.

My earlier comments on the technical limitations of HTTPS link rewriting (Thu 10/9/2008 7:10 AM PST) still apply; it is a problematic thing to attempt and probably should only be done when it's been validated that the service users will be accessing actually works when delivered thru a link-rewriting CT proxy.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Jo Rabin
Sent: Thursday, March 19, 2009 2: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 13:46:57 UTC