RE: ACTION-893: ... the security issues triggered by links rewriting.

CT Guidelines consider distributed clients like Opera Mini out of scope. Server side adaptation is also out of scope. We are specifically talking about in-network transformation by a third party. Though that isn't as clear as it might be in the following.

"Clients that interact with proxies using mechanisms other than HTTP (and that typically involve the download of a special client) are out of scope, and are considered to be a distributed user agent. Proxies which are operated in the control of or under the direction of the operator of an origin server are similarly considered to be a distributed origin server and hence out of scope."
[1] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-scope

So while I think that a discussion of Opera Mini is moot, I also think that further discussion may reveal some things that apply to the case that is in scope.

[Some of the points that follow make an appeal to the concept of "reasonableness". As per past discussions in this WG, this makes reference to the man on the Clapham omnibus [1] (that's "the hypothetical person on a hypothetical Bondi tram", Chaals)? ]


Use of a client like Opera Mini can't always be considered to be a user choice, though it may be. And users may not understand that there is a possible security issue in making that choice. Equally, though Chaals tells us that Opera Mini advertises its presence (presumably by setting the User Agent header value), and though most Content Providers will have heard of Opera Mini, in general they won't be aware of the precise construction of a User Agent. Whether it is distributed or not, as Chaals points out, may not be a determining factor in whether they consider such construction secure.

Making reference to discussion on this list, and also at Dennis Bournique's WAP Review [2] where members of the BPWG among others make some important points (see also Tom Godber's informative article linked from there [3]), I think the crucial point is "informed consent". 

Has the user given their informed consent, and has the content provider given their informed consent?

If a user has chosen a client, especially a distributed client, is it reasonable to infer that they have given consent to the interception of apparently secure communication? It's not clear to me that such consent is always informed and so I think that's a dangerous premise. If the user's consent is informed, how does the Content Provider know this, and do they know enough about how the User Agent works and what standards it is operated to, to be happy? 

Similarly to what Chaals points out below, although Mozilla may be trustworthy, Firefox is an intentionally extensible platform, so how can a Content Provider be sure that the user hasn't installed a plug in that steals their information?

Continuing on the theme of informed consent, but shifting focus to what's in scope for us, which is third party transformation ... given that this activity comes under the heading of OPES and given that this subject has been lengthily debated by informed people, we should make reference to the policy requirements that OPES lays down.
 
Section 2 of RFC 3238 [4] makes clear that similar impassioned debate has occurred around the whole idea of OPES, as has been taking place here. Notably the opening paragraph of that section:

   One view on OPES has been that "OPES is deeply evil and the IETF
   should stay far, far away from this hideous abomination" [ODell01].
   Others have suggested that "OPES would reduce both the integrity, and
   the perception of integrity, of communications over the Internet, and
   would significantly increase uncertainly about what might have been
   done to content as it moved through the network", and that therefore
   the risks of OPES outweigh the benefits [CDT01].  This view of the
   risks of OPES was revised in later email, based on the proposals from
   [Carr01], "assuming that certain privacy and integrity protections
   can be incorporated into the goals of the working group" [Morris01].

This is followed by:

   However, as we discuss in the next section of this document, we agree
   with [CDT01] that the one-party consent model by itself (e.g., with
   one of the end-hosts authorizing the OPES service, and the other
   end-host perhaps being unaware of the OPES service) is insufficient
   for protecting data integrity in the network.

Section 2 concludes with the following:

   (2.1) One-party consent: An OPES framework standardized in the IETF
   must require that the use of any OPES service be explicitly
   authorized by one of the application-layer end-hosts (that is, either
   the content provider or the client).

   (2.2) IP-layer communications: For an OPES framework standardized in
   the IETF, the OPES intermediary must be explicitly addressed at the
   IP layer by the end user.

The following summary considerations are presented in the following section:

   (3.1) Notification: The overall OPES framework needs to assist
   content providers in detecting and responding to client-centric
   actions by OPES intermediaries that are deemed inappropriate by the
   content provider.

   (3.2) Notification: The overall OPES framework should assist end
   users in detecting the behavior of OPES intermediaries, potentially
   allowing them to identify imperfect or compromised intermediaries.

   (3.3) Non-blocking: If there exists a "non-OPES" version of content
   available from the content provider, the OPES architecture must not
   prevent users from retrieving this "non-OPES" version from the
   content provider.


Comments in respect of the 3rd party proxy we are talking about. 

Ref 2.1: As noted elsewhere on this list, the current text of CT is somewhat unclear as to what it means by explicit user authorization. Firstly, does a network operator contract which authorises the use of a CT proxy constitute informed consent? We say not and although the text is not clear at the moment the intent as I remember it is for the user to give their consent on a case by case basis.

Ref 2.2: An inline proxy is not explicitly addressed, though other types of proxy are. However the question of informed consent comes in again here, so to what extent can a user reasonably be expected to understand that they are enjoying e.g. Google's transformed version of a site?

Ref 3.1: We have provided a means of CT proxy identifying itself, however, we have not provided a means of content providers determining to any kind of granularity what the nature of the CT services is. Indeed, although we do discuss the distinction between restructuring, recoding and optimizing the content provider has no means of determining which is to be applied, and therefore can't tell in the general case what will happen, and can't determine if they consider this to be inappropriate.

In the specific case of prior arrangement between the CT proxy and a content provider, a content provider can consent to the service on the basis of "offline" a priori inspection etc. But in general this is not the case.

Ref 3.2 and 3.3: We do say that in all cases the user should be able to access a non-transformed version of the content. Though, paradoxically, the nature of that content and their device may make it impossible to form the kind of judgment that this 3.2 seems to be aiming at.

So in conclusion, this issue is broader than HTTPS link rewriting. Prior arrangements between CT Proxies and Content Providers are out of scope, Opera Mini is out of scope, but forms a good illustration.

I've run out of time before the call.

Jo


[1] http://en.wikipedia.org/wiki/The_man_on_the_Clapham_omnibus
[2] http://wapreview.com/blog/?p=2653
[3] http://blog.masabi.com/2009/01/how-do-transcoders-affect-https.html
[4] http://tools.ietf.org/html/rfc3238



> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Charles McCathieNevile
> Sent: 03 February 2009 12:02
> To: Tom Hume; Mobile Web Best Practices Working Group WG
> Subject: Re: ACTION-893: ... the security issues triggered by links
> rewriting.
> 
> 
> On Tue, 20 Jan 2009 23:47:15 +0100, Tom Hume
> <Tom.Hume@futureplatforms.com> wrote:
> 
> >
> > I've built sites myself that fit that criteria. For instance - an
> > iTunes-style music store for a startup I worked for in 99. HTTPS for
> > login, just to protect the password, but beyond that no need for HTTPS.
> > No credit cards stored or anything like that.
> >
> > In that case, as a content provider I'd be happy for mobile users to be
> > able to access their MP3s through a transcoded version of the service...
> > and would be happy to have security slightly degraded.
> 
> And this is the crux of the issue. A few people use HTTPS because they
> somehow think that it won't allow transformation services. In practice,
> that is clearly not true - any service where the the client is distributed
> (such as Opera Mini) will still work.
> 
> Opera Mini is a two-part client. One part is installed on the end-user's
> telephone, and it interprets contentsent by the other part. The other part
> is maintained "in the cloud", and is a process running which communicates
> to the service being used, and then makes that legible for the user's
> endpoint.
> 
> If you think of an XWindow server, would it make sense to say that anyone
> using HTTPS insisted that the browser was not running remotely over X? I
> find that hard to believe. So why does it matter when the browser is
> running over Opera Mini's customised process? (There is of course an
> orthogonal argument about how secured the internal processes are, whether
> in a distributed client system or in a common or garden browser. But that
> isn't relevant here except to sites which deliberately block certain
> browsers because they are not sufficiently secure).
> 
> If this seems odd, then please explain the opposite - in what way is it
> not a set of distributed processes communicating with each other? That is
> how all but the most elemental software works. And software like screen
> readers make themselves what Luca is calling a "man in the middle"
> directly intercepting the video stream at times. Yet we don't generally
> see people trying to block this transformation.
> 
> As Francois also pointed out, as well as Tom's case (which I think it
> pretty common, just mentally flipping through top sites) HTTPS doesn't
> secure the other end very well either - EV certificates are the baseline
> for suggesting that it might, and they are still not that common.
> 
> In other words, we have a protocol that, between two end points which know
> nothing much about each other, blocks unknown third parties from listening
> in. It says nothing at all about what happens at *either* of those end
> points - and not should it.
> 
> Assuming that HTTPS means "I insist on knowing the precise browser model
> of my user, and only accept certain variations" seems a stretch. There are
> systems that blacklist Opera Mini (and all kinds of other browsers), and
> Opera Mini is careful to identify itself. I think that clearly a
> transcoding system should identify itself - but I don't believe that the
> majority of sites using HTTPS give two hoots about transcoding systems any
> more than they care to block browsers known to have major security
> problems.
> 
> So this talk of "abusive business practices" strikes me as nonsense. A few
> organisations who are particularly paranoid or have extremely tight
> requirements already block services such as Opera Mini. Many others are
> very happy to have it working or have gone out of their way to make it
> work (still using HTTPS), and in any case are not using HTTPS to suggest
> that content should not be transformed at all (that horse was never even
> in the web stable - browsers  decide on their own how to transform
> content, and have always done so in different ways). End users are
> choosing to use services, and how much data to provide to those services,
> whether that be a single piece of software installed on their machine or a
> distributed process or set of processes the user daisy-chains together on
> their own. Somehow suggesting that users should not be able to do this,
> because people offering web content and services to them don't like the
> idea, seems to me an argument that doesn't reflect much of reality (would
> Luca's your "95% of cases is good enough" test, for example).
> 
> Transparent proxies are a slightly different kettle of fish. They have
> been a part of the Web since the early days - since the beginning of the
> mobile web. While HTTPS has had the effect of not letting them interfere
> with a transaction, this is because their model is fundamentally different
> to services the user has chosen. If the user chooses a browser which
> distributes processing (or an acceleration service) then it is an obvious
> corrollary that they accept the distributed service handling their data.
> If some operator places this in the way and does not inform the user
> (because they provide a browser that doesn't explain its terms of service,
> for example), then that is to do with sales and advertising practices
> providing information to the user, not with the technology itself.
> 
> Something that strikes me as a more profitable alternative for a group
> recommending best practices in this area is that they indeed outline
> processes and protocols for data security in intermediate systems.
> 
> Some simple ones would be restrictions on data stored and on handling of
> data storage,
> 
> Trying to stretch a directive that says "this presentation is already
> optimised for your client, you don't need to try and make it look better"
> into "I am not prepared to offer this service to your system because I am
> not happy about the security of it" seems as big a stretch in the wrong
> direction as claiming "I want a connection to the client where no
> *unknown* third party can drop in" also means "and I am not prepared to
> work with a client model that has distributed processing".
> 
> cheers
> 
> Chaals
> 
> --
> Charles McCathieNevile  Opera Software, Standards Group
>       je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 3 February 2009 14:05:53 UTC