- From: Francois Daoust <fd@w3.org>
- Date: Mon, 19 Jan 2009 18:47:50 +0100
- To: Luca Passani <passani@eunet.no>
- CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
I see "HTTPS is end2end security" being exchanged in the discussion. I can't help thinking that there is a "yes, but" here. HTTPS is end2end security, but one of the ends is usually not identified, or rather not "properly" identified. There is an asymmetry in the way HTTPS is being used today: server-side certificates are the rule, while client-side certificates are reserved for very specific needs such as access to corporate intranets, or income tax declarations. The use of client-side certificates makes it possible for servers to assert that the end-user is really the end-user, because the authentication is inherently more secure when the user is asked for something he knows (password) *and* for something he has (certificate). It would make it possible to reject ends that are actually something in the middle, or someone else who happens to know the user's credentials. What I find interesting is that there has been support for client-side certificates for some time on desktop-browsers (I do not know if that is the case on mobile browsers, but that's not really the point here) and yet it didn't take (or hasn't taken yet, it all depends on your point of view). Client-side certificates come with a series of shortcomings. They are a pain to install, understand, and use. They need to be installed on all the devices a user may use to browse the Web (or carried out on a USB key). Besides, they could be stolen, and in the particular case of Content Transformation, delegation mechanisms could also be used to make them available to proxies anyway. In short, the solution is not so wonderful. But, if Content Providers truly wanted to protect their data more than to enable the ease of access, client-side certificates would be much more of a rule, and users would have been educated on them. The man-in-the-middle possibility has always existed and is the base of most phishing attacks. In short, there is a trade-off on security when HTTPS is used without client-side certificates. The conclusion I draw is that I don't think we can infer that Content Providers must be opposed to transcoding because they use HTTPS. Francois. Luca Passani wrote: > > 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. > > Luca > > >
Received on Monday, 19 January 2009 17:48:23 UTC