RE: Comments on Content Transformation Guidelines?

To clarify, I'm not making any claim of superiority for the
quality/reliability of transcoding vs non-transcoding. There are always
value judgements occuring when we consider such tradeoffs, and your
assessment will be different from mine.

But the value of transcoding as a tool is similar to why many people buy
on credit: you could say that if we were perfect we would be excellent
money makers/managers and never need credit. But we are not perfect, and
markets have undoubtably grown because the users were provided that
"service", regardless of what it's meant to our ability to learn money
management skills.

The 95+ percent of users who have mobile browsers that are not "whole
web" capable are currently shutout of accessing anything but the "mobile
web". I don't think anyone is expecting the CT Guidelines to be anything
but an aid for increased web penetration, as we transition to "whole
web" capable browsers. That transition is likely to take a few more
years, thus there is time for value to be gained from vendor and service
provider investment in these types of services. Otherwise the BPWG
members would not be spending their resources supporting this work.

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-request@w3.org] On Behalf Of Sean Owen
Sent: Monday, August 04, 2008 4:06 PM
To: Luca Passani
Cc: public-bpwg-comments@w3.org
Subject: 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:26:13 UTC