Re: Comments on Content Transformation Guidelines?

Sean Owen wrote:
> 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.
>   
The problem here are not opt-in transcoders. The problem are transcoders 
which operators place in the middle of HTTP. Those have the potential of 
screwing everything up for mobile developers, big and small. This is is 
why transcoders need to carry the burden of protecting mobile sites at 
all costs. Even when those mobile sites do nothing to advertise the fact 
that they are mobile.

>
>   
>> 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.
>   
you are mudding the water, Sean. By the same logic, I could say that 
airplanes exist, but this is not a good reason to crush a couple of them 
on the WTC.
> Oh but you're talking about transforming proxies. Yes, good point, but
> certainly HTTP itself has no problem with this concept.
>   
reality is that something as devious as transcoders were not even 
coinceivable when the proxyes were defined. We are talking about a tool 
which captures and transform content it has no right too. So, the fact 
that HTTP was not devised with a feature that prevented transcoders from 
stealing content, does not mean that it is OK to do so. Thousands of 
developers around the planet think it is not.
>
>   
>
> In all cases here, 1) the communication between server and client are
> encrypted,
it's no longer end2end

>  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.
>   
it's not just "just". It's about compromised security.
> 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.)
>   
And what will the bank say about this?

> 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?
>   
this to me is like: I am a legitimate customer of a bank. The bank wants 
me to go through the main door (they have anti-rob security there), but 
someone will open a secondary door for me. Since I am a legitimate user 
of the bank, using the secondary door is no big deal......ermmmm...not 
quite. This is not how it is supposed to work.

>
>   
>> 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?
>   
I don't think the bank is "consenting" in this case. Also, how many 
users understand security? Personally, I would say that I am familiar 
with security issues, but "understand" is a big word when it comes to 
security. Users will not understand the security implication. They will 
say "yes" and opt for less security, which invalidates the whole notion 
of security.

> 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?
>   
Yes. This is one way to put it. When it comes to security, users need to 
be protected from themselves. And I am amazed at how you are failing to 
agree with this.

>   
>> 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.
>   
which is not what I said. The content should not be available unless the 
content owner decides that it should in fact be available and build a 
mobile UI for it.

>> 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.
>   
Who are the 19 people? I talk to developers each day. I would say that 
95% or more think you have done a poor job by not protecting mobile 
content enough against abusive trascoders.
> I look forward to supplying some last call comments to your next
> document? do you take any outside input? it's tough. :)
>   
Are you referring to the Manifesto?

http://wurfl.sourceforge.net/manifesto/

comments can always be posted on WMLProgramming

Luca

Received on Tuesday, 5 August 2008 07:57:13 UTC