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 Wednesday, 11 March 2009 09:40:45 UTC