Re: Comments on Content Transformation Guidelines?

Sullivan, Bryan wrote:
> Hi Luca,
> There is perhaps a difference between "attack" and "service". What the
> CT Guidelines focus on is the delivery of a service. Every tool may of
> course be usable for undesirable ends, but that is little justification
> for remaining in the stone age.
>   
Bryan, are you saying that transcoders are a way to "get out of stone 
age"? if this is the case, I think that our discussion will not be 
simple, because I happen to think that transcoders are bringing the web 
*back* to stone age.

> There is an assumption of user trust in accessing and using a service.
> That trust should be established via informed consent. Once established,
> the terms of service should be adhered to, including disclosure of HTTPS
> link transcoding (however disclosed).
>
> If the user trusts their service provider (e.g. CT Proxy Operator,
> whoever that is, whether associated with their network service provider
> or not), then they should have the right (barring local legal
> constraints) to access HTTPS links via CT proxies. Of course, it's only
> useful to do so *if* they can get it to work reliably enough. I have
> earlier pointed out some weaknesses in the technical feasibility of
> this.
>
> To Sean's point, "SSL can be used to authenticate the client as well but
> I have never seen this used in practice even on the desktop. Surely it
> is not used in mobile?": I know of no instances of client certificate
> use by mobile browsers, at least in the US market.
>
> WAP Gateways can be configured to do domain-name checks on SSL server
> certs, but that is the only validation that I am aware of, and it is
> specific to WAP1. It's reasonable that mobile devices can do the same
> (they need the root certs anyway), but the user experience issues (SSL
> server certs are often out of sync with the hostname via which HTTPS
> links are served) mean that user prompts on domain validation errors
> would likely soon be turned off by the user. The point here is that
> users are often trusting that unauthenticated (or at least
> server-authenticated) SSL encryption is good enough. This included
> operation across the famous "WAP gap" of WAP1, which not
> unsignificantly, supports many successful banking and brokerage services
> offered to mobile users. WAP2 of course provided true end2end security
> as one of its main objectives, but as users sometimes find out, the
> direct pipe does not always deliver compatible content.
so, the answer has to be "dear content provider, if you use HTTPS, make 
sure that the content you deliver is compatible with the capabilities of 
the client, or the page won't work".

Right now your message to developers is "stop doing mobile development. 
Someone smarter than you has come up with the technology that will 
reformat your web site for all the phones. If you really insist, I'll 
tell you that end2end security gets compromised in the process, but you 
don't need to care about it because your network operator is so totally 
trustable that it makes no difference"

Luca

Received on Monday, 4 August 2008 22:49:55 UTC