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: Luca Passani <passani@eunet.no>
Date: Sun, 18 Jan 2009 23:14:15 +0100
Message-ID: <4973A9B7.3080401@eunet.no>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

David Storey wrote:
>> sure, but if they introduced HTTPS it means that security has 
>> priority over reaching the widest possible audience, or they wouldn't 
>> be using HTTPS.
> The users information is kept as secure using Opera Mini, as a regular 
> browser, IMHO.  Whether all proxies or proxy based browsers are run by 
> trust worthy companies is a matter for debate that I'm not willing to 
> go into.

I think you are avoiding the point I raised. I repeat. If a content 
owner goes the length of requiring that its content is accessed through 
HTTPS, it must mean that they place security one level above the need to 
maximize ease of access. If you don't think this is the case, ask them 
and whitelist them. Obviously the onus must be on Opera, not on them. 
They have already done their part.

>> Very good. So what about starting maintaining a whitelist of sites 
>> which have explicitly approved that OperaMini interferes with HTTPS?
>> I wouldn't have a problem with that. And this would effectively make 
>> Opera a more ethical company than, say, Novarra and the others.
> There are far too many sites using HTTPS to make this a viable 
> solution.  Just getting in touch with all those sites would be near 
> impossible.

There are many sites, but you have statistics. You know which sites are 
the most popular. Go for the top 200, and add 50 each month. Long tail 
typically won't use HTTPS. Very feasible if you really care about 
respecting the rights of content owners.

> A blacklist may work.  We'd also end up with no users left while we 
> waited for just the popular sites to get back to us with an answer. 
> Never mind the long tail.

congratulations! You just figured out that honesty comes with a price.

>>> 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.
>> Most sites won't do that because they are not aware of what OperaMini 
>> is. I am sure that some sites will get there eventually. The problem 
>> is that you are breaking the web as a platform in the process by 
>> making development much more complicated and hard to test and maintain.
> I'm not sure how this is the case.  Most sites that work in Opera will 
> work out of the box with Opera Mini.  Additional testing is mostly 
> just having another browser to test against.  The main difference from 
> a developers angle is the JavaScript restrictions caused by a client 
> server architecture, as highlighted at 
> http://dev.opera.com/articles/view/javascript-support-in-opera-mini-4/
> As a full browser wouldn't fit on many of these phones it is allowing 
> the web in places where it wouldn't be able to reach, rather than 
> breaking it imho.

I was referring to regular full-web sites. Those will typically not 
perform any kind of adaptation. They will be unable to tell a mobile 
browser from a web-browser. In particular, they will not recognize 
OperaMini. Those sites are being fooled by your proxy. Are you sure that 
content owners are OK with that?

>>> I don't know the exact details of Opera Mini security, but we don't 
>>> store sensitive data.
>> An unfaithful employee might be monitoring and recording unencrypted 
>> sensitive data in the server memory.
> A hacker may be doing the same on your desktop PC.  Internal policies 
> would quickly find out if this was the case (and much faster than a 
> regular user would find out if their computer had been hacked).
Still. HTTPS is about end2end security and the OperaMini proxy is 
breaking it without consent of (at least) one of the parties (that's 
assuming the user knows what is doing, which is not always the case. Or 
it would be without the knowledge of 2 parties).

>>> 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.
>> the majority of what users request is not HTTPS. A large chunk, but 
>> not the majority. So, no, you don't need to.
> Any site that requires a log i would not work. That is a big 
> percentage of the top ten sites in the top 10 markets for Opera Mini.  
> Any proxy based solution needs to support logging into sites. That is 
> commercial and user experience reality.
> If there was another way then fine, but currently there isn't.

As I said, figure out the top 200 sites which require HTTPS-login, 
contact the owners, explain the situation and get their approval to 
whitelist them. Very feasible.
"but they may say no?!" I hear you say. Yes, of course they may. That's 
the whole point.

Received on Sunday, 18 January 2009 22:14:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC