Re: Comments on Content Transformation Guidelines?

On Mon, Aug 4, 2008 at 7:48 PM, Luca Passani <passani@eunet.no> wrote:
> yes. So what about stating in the CT guidelines that transcoders should be
> opt-in?

I think that's a reasonable position to take. It's not the one I would
take, nor apparently people here. I think you should write your own
document too.


> If operators start placing transcoders in the middle of all HTTP requests
> then it is not a service anymore. It's hijacking the HTTP protocol, which
> poses hurdles to content owners and developers.

If God had not intended proxies to exist, He would not have given us
the 305 status code. Among other things. I understand your point that
you don't like transcoders and have identified issues with them. I
know you understand HTTP and HTTPS, so I suppose I would just point
you back to RFC 2616 to refresh your memory. It definitely does have a
notion of proxies.

Oh but you're talking about transforming proxies. Yes, good point, but
certainly HTTP itself has no problem with this concept.


> when a site owner has decided to implement HTTPS, they have already
> expressed the need to protect all communication between the client and the
> server beyond reasonable doubt. Stating that there may be cases where
> content owners are still open to the possibility that someone messes with
> their content and/or their communication channel with the client means
> defying all logic and betraying the intentions of the content owners. As an
> aside, isn't this what a rapist might argue? (she said no, but it was clear
> to me that she meant yes).

In all cases here, 1) the communication between server and client are
encrypted, and 2) the server has authenticated itself to the client.
It's just that we have two servers, and two clients involved:
server/proxy, and proxy/device.

I think the point here is that the transforming proxy *should only*
operate with the consent of the user. If so, then the proxy is
effectively "me" to the bank or whatever site this is. And, indeed, we
have a secure HTTPS connection between "me" (my proxy) and the bank.
(Separately, I'm talking securely to the proxy.)

If the proxy is operating without the consent or understanding of the
user, I totally agree with you. Not cool. Not the bank's intent, not
my intent. If the user thinks the connection is end-to-end secured
with the bank, not OK. This whole scenario only makes sense if you
trust and understand the proxy.

But if you do... what is so wrong with this?


> HTTPS = Do NOT transcode.

I wholeheartedly agree that it should not happen unless the user
understands the implications. Beyond that, hey, consenting adults can
do what they like?

Perhaps you are trying to argue that users should be protected from
themselves and not allowed to do this even if they think they want to.
I think that is at least a coherent position, if not one I agree with.
Is that what you mean?


> Also, since the majority of the content is regular HTTP these days, I can't
> see why excluding HTTPS would be such a big deal.

Gosh, it seems extreme to say this content should just never be
accessible to mobile users.


> that's what the CT guidelines are supposed to be for. You don't listen ->
> you are not complaint.
> It's as simple as that.

Sure, so the goal is to write something people think is worth reading.
I am glad someone is out there portraying this as a criminal/victim,
good/evil situation. Someone has to do it, there's an audience for it.
I am glad you put in some concrete suggestions here too. I guess I
think you could reach a much wider audience with a different approach.

But I dragged this way off topic. I think the comments that started
this thread are largely good ones, I'll leave it at that. I don't
think anybody is going to convince anybody of anything here. 20 people
don't have agree. 19 do here, good enough to publish.

I look forward to supplying some last call comments to your next
document? do you take any outside input? it's tough. :)

Received on Tuesday, 5 August 2008 00:14:59 UTC