W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

Re: FYI - "Mobile Web 2009 = Desktop Web 1998"

From: Charles McCathieNevile <chaals@opera.com>
Date: Mon, 09 Mar 2009 01:16:21 +0100
To: "Luca Passani" <passani@eunet.no>, public-bpwg@w3.org
Message-ID: <op.uqh0djtuwxe0ny@widsith.local>
On Sun, 08 Mar 2009 23:27:06 +0100, Luca Passani <passani@eunet.no> wrote:

> Charles McCathieNevile wrote:
>>
>> Perhaps you could ask them, before asserting that they made a positive  
>> statement without checking obvious public sources.
>
> Sounds like Opera has been dealing with Berkley?

That's "Barclays", and *as far as I know* we have not had any dealing with  
them, let alone on this specific issue. I could of course be wrong, and I  
will ask, but meanwhile I cannot send you a contact since I have none. I  
do *believe* (based on half-remembered conversations with RNIB people from  
years ago that are not reliable sources) that they have worked with the  
RNIB on accessibility.

> can you send me a reference? also offline. Yes, I would like to take  
> contact and ask Barclay's why they decided that it's OK that a  
> third-party company breaks the secure communication between them and  
> their customers.
>>
>>>> Opera mobile does not "attempt to redefine HTTP".
>>>
>>> with reference to past discussions on this list, I think this is  
>>> arguable (ref: HTTPS and how it can be legitimately tampered with).
>>
>> Anything is arguable.
>>
>> However, Opera does not attempt to redefine HTTPS. It provides a  
>> connection from any web service chosen by a user to the Opera server  
>> that is secured. Since it needs to render the site at that point, it  
>> does so, and in the spirit of HTTPS provides another secured connection  
>> from the secured rendering service to the user's handset.
>
> I won't discuss this again. HTTPS is end2end. Opera Mini is about:
>
> Web server <-> Opera Proxy <-> OperaMini
>
> which is not end2end. Full stop.

The problem is that HTTPS does not define the ends *either*.

Webserver <-> Interenet Explorer is, I guess, their most common model. But  
the connection "content provider <-> Web server" is not defined anywhere,  
and except in teh case of EV certificates it is not even clear to the user  
who the content provider really is.

The *endpoint* at the client side is clearly not a user, it is a software  
product. Whether users choose to trust that product depends on all kinds  
of things, and when Opera Mini did not encrypt the connection to the user,  
it said so quite clearly (since the issue is really whether any unknown  
third party can eavesdrop on the connection and make a man-in-the-middle  
attack).

So if you won't discuss this again I will refer in future to the rest of  
the group. But let's leave the network issue aside for a moment, and  
return to the question of rendering content...

>> I simply don't see the logic in your assertion. So let me rephrase what  
>> I understand your position to be, to ensure we are talking about the  
>> same thing...
>>
>> A content owner decides to put up a web service, and open it to all  
>> comers.
>> If a technically savvy user decides to look at it in a way customised  
>> by that user, this is fine.
>
> not what I said. I said that users are taking the responsibility for  
> their actions. Not very differently from when one exceeds the speed  
> limit because they feel safe and they think that no police is there to  
> check. I wouldn't say it's fine (oops...a pun). I would say that if they  
> do it, chances are that they get away with it.

OK, so now I have a clearer picture of what you are saying is bad. Being  
able to clarify it helps.

So you are arguing that a user should not be changing in any way the  
presentation, but may indeed get away with it. What about a user who has  
very poor vision, and decides to use a screen reader to interact with the  
content? How do you account for the UK government's decision to make this  
a legal requirement, and the Australia court decisions to validate that in  
case law? Are they wrong? Should people who could not use the service  
visually have been denied access?

>> If an ordinary user chooses a service to look at it in a way that  
>> apparently suits that user, that is not fine.
>
> Correct. This would be like a service that says: we will disable all  
> speed checking equipment until you get home. I don't think the police  
> would be very happy about this.

In your analogy that relates changing presentation to speeding.

So if it were determined that it is reasonable for a user to transcode  
content, would you be happy about people providing services? I.e. is the  
core of the issue that content presentation should not be tampered with  
(but for pragmatic reasons it isn't worth worrying about individuals) or  
is there some reason that providing a service to do so is intrinsically  
wrong even if it were reasonable for users to do this themselves?

To take another example, there are companies that make content accessible  
(in the WAI sense) by providing on-the-fly adaptation. Obvious examples  
are screen readers, but there are also products that are distributed  
through the network. Is their work also illegitimate? Or does it  
fundamentally depend on the reaon why the adaptation is made, or on how  
the adaptation is done, or only apply to certain adaptations?

>> What I fail to understand is
>> 1. The difference between a person choosing their own modifications,  
>> and a person choosing a service that does the modification for them.
>
> the service is helping people perform an illegitimate operation.

OK. So as I currently understand it, the core question is whether this  
operation is illegitimate.

>> 2. How this difference is somehow importantly different to the capacity  
>> for different browsers to have different rendering engines (it doesn't  
>> come a lot more different than silent onscreen presentation and  
>> presentation in voice, for example).
>
> It is different. By placing the transcoding in the network, HTTP is  
> disrupted and the capability of existing services to serve content  
> tailored to mobile devices is severely impaired.

Let me leave aside the point about User Agent spoofing for a moment. If  
the service provides an identifier for the rendering engine, and an  
identifier for the device, then is this qualitatively different to the  
fact that IE and Firefox don't apply the same rendering rules, but do  
announce what they are and what OS (if not device) they are running on?

>> (What I further fail to understand is why Opera Mini, which makes every  
>> effort to provide the intended rendering, and
>
> half of your sentence is MIA. So I won't comment on this.

It was that Opera Mini makes a lot of effort to provide the rendering  
desired, and in the service we offer to the public there is information  
provided specifically to enable developers to figure out where it is  
coming from. But let's leave that aside for now, since it is oprational  
detail about one particular service.

[effectively repeating]

>> I also think it is a misleading example, since Opera Mini is *not*  
>> equivalent to converting the colour movie to Black and White on a  
>> colour TV. It might be more appropriate to use an analogy of it  
>> displaying TV on a mobile phone, where that may be a Black and White  
>> phone. (It is an imperfect analogy still, but I think closer to the  
>> reality).
>
> I did not have any particularly hard feelings against OperaMini because  
> 1) it was typically opt-in for users and did not impact deployed mobile  
> applications all that much  2)  I stilll did not know that you sold the  
> rendering engine to ByteMobile and BM was using it for their transcoder  
> in OperaMini's name. Now that I find you and your Opera colleagues here  
> going out of your way to defend transcoders, I have no choice but to  
> speak up: transcoding without the consent of copyright owners is  
> indefensible.

Opera Mini is still opt-in for users. Who seem to be opting for it in  
numbers that I suppose do impact mobile applications. (And desktop  
applications).

To be clear. I do not think that all transcoding is intrinsically good,  
but nor do I understand any argument that it is intrinsically evil. I  
think there are some kinds that make very good sense and are beneficial,  
some kinds that should be used with care as they have potenital benefits  
and potential drawbacks. There may be some kinds that I think are just bad.

(Note that this is not a mobile-specific discussion, and that I have some  
serious reservations about how you are defining "transcoding", but for the  
sake of getting further clarity into the discussion I would prefer to  
leave those issues aside for now).

>>>> If your site can be found in Google,...
>>>
>>> I find this situation you describe profoundly different from  
>>> transcoding the whole page without the consent of the copyright  
>>> holder, often stripping out ads and banners which constitute a site's  
>>> business model (not to mention the case when operators inject their  
>>> own ads in the process).
>>
>> So do you really object to rendering a page somewhere, and providing  
>> that rendering somewhere else? Opera Mini, and the X Server running a  
>> web client and rendering it for me on a terminal somewhere else are  
>> both doing this, and so is lynx over an Xterm, and so is using a  
>> virtual screen to remotely run my browser.
>
> there is a not so little difference. As a content owner, I have the  
> possibility to identify Lynx and serve Lynx-optimised content or no  
> content at all. For simplicity, most content owners will simply ignore  
> lynx.
>
> With transcoders, the network owner is interfering with how HTTP has  
> worked until today to change the way my application works against my  
> will. This is NOT OK.
> You may start arguing about "via:" header, "no-transform:" and  
> "x-device-", but this is not the way HTTP has worked until before  
> transcoders where put in the middle of all HTTP requests  (which is  
> exactly the moment when developers went up in arms against transcoders),  
> so my point stands. You MUST leave HTTP alone.

How do caching proxies (which have been in the network almost forever, in  
many cases unannounced and almost undiscoverable) fit into this picture?

...
>> Or is the issue really that you object to some specific kind(s) of  
>> transformation?
>
> I object to transformations happening in the network. Whatever the  
> network, content owners have the right to see their content served to  
> clients exactly as they have sent it.
> Please observe that I am still leaving plenty of space for "honest"  
> transcoding. Operators might launch developer programs and partnerships  
> to have third-party companies subscribe to Operator's transcoding  
> service. At that  point, content owners would  be the ones which  
> subscribe to the transcoding and all problems would be solved.
> Of course, this would mean a lot less stuff to transcode (at least  
> initially), but it would be happening much more cleanly and in peace  
> with the rest of the ecosystem.
>
>> I think that is a seperate discussion, but one I can see as making  
>> sense, and one I think the CT work should address.
>
> They merged the CT mailing list back into BPWG, so we are already on the  
> right list.

Yeah, I mean that there are likely some points to be extracted from your  
assertions that I agree are valid items for CT to talk about, although I  
disagree with your assertion that transcoding is inherently wrong.

> Cheers

likewise

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Monday, 9 March 2009 00:17:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC