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

Re: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

From: David Storey <dstorey@opera.com>
Date: Sun, 18 Jan 2009 20:20:14 +0100
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Message-Id: <2DC581B7-FC51-414B-810D-89EFBCFA44A8@opera.com>
To: Luca Passani <passani@eunet.no>


On 18 Jan 2009, at 17:12, Luca Passani wrote:

>>>
>>
>> Wouldn't work.  Opera Mini only supports transcoded content.   
>> Without it we'd have to show a screen saying "site not supported"   
>> Not exactly good user experience, or what the user wants.
>
> right. Not a good user experience. But totally against what the  
> content owner may want.

Maybe, maybe not.  The content owner probably wants their content to  
reach as wide a audience as possible.  Our "state of the mobile web"  
reports (http://www.opera.com/smw/) show that the most popular sites  
are social networking sites, and to some extent e-mail.  Both need the  
user to log in via https.  All those sites would just stop working.   
Those sites would loose the 20+ million  potential users.  We know of  
at least one major social network that Opera Mini is a substantial  
portion of their daily hits. They'd certainly not want us to cut off  
the users.

Should a content owner be able to say users in the developing world  
that can only access the web through a proxy based browser like Opera  
Mini (the top countries for Opera Mini are dominated by developing  
nations, and the main devices are regular feature phones, not advanced  
smart phones). can't access their site?  That sounds like  
discrimination to me.

> If I make the effort to create an HTTPS site, it may well mean that  
> I don't want anyone to interfere in the communication between me and  
> the client, don't you think?

Technically if the client is on the server, it is not strictly doing  
this. The user requests the page from Opera, Opera requests and  
receives the page from the site. Opera then sends the result (using  
SSL) to the Mini client.  If you really wanted to, you could just  
block Opera Mini by browser sniffing.

I don't know the exact details of Opera Mini security, but we don't  
store sensitive data.
>
>
> After all, also waiting in line is not a good user-experience. Users  
> have the right to complain about the long wait, or just vote with  
> their feet and go somewhere else.

Sometimes there is no option to go elsewhere.  There are sites where  
you only have one option (example: government sites, local authority,  
etc.)

> They do not have the right to walk behind the counter and help  
> themselves (i.e. break HTTPS).
>
>>  If a browser supports both regular html and transcoded content  
>> then I personally fully agree, but otherwise we need to serve the  
>> content.
>
> again, you don't need to. You want to. And you do it with the hope  
> that nobody gets seriously mad at what you are doing.

Well it wouldn't be called a browser if it couldn't serve the majority  
of what the user requests, so yes we need to.
>
>
>>
>> Opera Mini exists to run on phones that wouldn't support a full  
>> browser.  Users do also run it on smart phones as it saves the user  
>> money in data traffic (and assumably the operator in data traffic  
>> costs).
>
> well, operators make money on data traffic, but let's not go there,  
> it would be a digression.
Flat rate plans.
>
>
> Luca
>

David Storey

Chief Web Opener,
Product Manager Opera Dragonfly,
Consumer Product Manager Opera Core,
W3C Mobile Web Best Practices Working Group member

Consumer Product Management & Developer Relations
Opera Software ASA
Oslo, Norway

Mobile: +47 94 22 02 32
E-Mail: dstorey@opera.com
Blog: http://my.opera.com/dstorey
Received on Sunday, 18 January 2009 19:20:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC