Re: Comments on Content Transformation Guidelines?

Could we agree that a transcoder can be a "service" sometimes? On my
little old phone it's the difference between seeing 99% of the web and
not seeing it. I can't imagine I'd prefer to not have a transcoder
available. But it sure raises some issues for content providers, for
security, and more. Transcoding is neither always good or always bad.
I don't agree, and I don't think Bryan is saying, that automated
transcoding is always superior or something.

I think you're telling me, too bad, I should not be allowed to see the
part of the web accessed via HTTPS on my phone, since it's evil to
transcode HTTPS. I think I'd rather understand the situation and make
that decision rather than have it decided for me. I am sure you
wouldn't want to be told what think on this question either.

I don't think anyone is arguing with the problem you identify. I don't
think it leads to the heads-in-the-sand conclusion that nobody should
ever attempt to transcode an HTTPS resource. Instead, at least, folks
here are trying to write down a doc that points out that this is
really a sticky situation and one should make sure the user is
informed about the situation.

I'd rather write this down, than not write it down, for the benefit of
people who may not be thinking about this at all when setting up a
transcoder. You could write "never do this, you're evil" but I think
the guy who's trying to figure out how to make that https site work on
a mobile is just not going to listen to that kind of message. What's
wrong with explaining the problem instead?


On Mon, Aug 4, 2008 at 6:49 PM, Luca Passani <passani@eunet.no> wrote:
>
> 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 23:07:07 UTC