W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: Comments on Content Transformation Guidelines?

From: Luca Passani <passani@eunet.no>
Date: Tue, 05 Aug 2008 01:48:20 +0200
Message-ID: <48979544.3010206@eunet.no>
To: public-bpwg-comments@w3.org

Sean Owen wrote:
> Could we agree that a transcoder can be a "service" sometimes? 
yes. So what about stating in the CT guidelines that transcoders should 
be opt-in?
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.

> 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 think you are defending the indefensible here.


"*HTTPS* is a URI scheme <http://en.wikipedia.org/wiki/URI_scheme> used 
to indicate a secure <http://en.wikipedia.org/wiki/Secure_communication> 
HTTP <http://en.wikipedia.org/wiki/HTTP> connection."



"*Secure communication* includes means by which people can share 
information with varying degrees of certainty that third parties cannot 
know what was said."

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).

> 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.
yes, it does.

>  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.
the situation is tricky because you want it to appear tricky. 
Unfortunately for you there is no wiggle room.

HTTPS = Do NOT transcode.

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.
> 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.
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.
>  What's
> wrong with explaining the problem instead?
explain the problem and explain why messing with HTTPS is not OK.

Received on Monday, 4 August 2008 23:48:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:10 UTC