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

Re: ACTION-893: ... the security issues triggered by links rewriting.

From: Tom Hume <tom.hume@futureplatforms.com>
Date: Wed, 4 Feb 2009 18:33:55 +0000
Message-Id: <2FB5C180-7E7F-4ABD-AF36-54A86D944AB5@futureplatforms.com>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>


On 4 Feb 2009, at 18:12, Charles McCathieNevile wrote:

> While she may not understand the fine details, and you could argue  
> about how informed her consent was, I think it is pretty clear that  
> she has in fact changed her configuration.

I agree, but she's of a class of user (not insignificant in mobile- 
land) who may not even know what a browser is, never mind understand  
access points or security models.

>>>> Well exactly... but there are mechanisms which have been promoted  
>>>> for saying "it's secure now", including the padlock icon. And in  
>>>> the case of transcoded HTTPS they're not actually correct any more.
> It isn't that they are not correct any more. The padlock said "there  
> is a secure connection as part of this transaction". It never said  
> where to, or where from - in other words it was accurate but not  
> very useful information. That's why browsers have been working to do  
> things better for as long as the MWI has existed.

I think the public perception of the padlock is "I am safe", and  
there's a risk here, if security is degraded without the end-users  
knowledge. I don't think it's a technical issue actually

>> Some might argue that having degraded security whilst believing you  
>> have true end-to-end is worse than knowing correctly that you have  
>> no security at all.
> Indeed. But the logical conclusion is to do away with the padlock,  
> and stop telling people that HTTPS is something it isn't.

Hmm... I suspect the option of rewriting all browsers and reeducating  
the public is one of the least available ones to us.

>>>> The balance of risk is not simple. Transcoders are potentially  
>>>> richer targets for crackers, but also generally have far better  
>>>> mechanisms for detecting both a crack and an attempted crack.

I'd like to know more about this, actually - though I suspect it's a  
bit of a rat-hole for us...

>>>> ...or access the HTTPS service from a HTTP-provided page which  
>>>> has been transcoded without the users knowledge - e.g. the search  
>>>> results page of a search engine. So I'm not sure this assumption  
>>>> holds.
> Let me distinguish again between a man-in-the-middle *attack* and a  
> user-selected service. The former case can easily arise in the use  
> of unencrypted HTTP through packet-sniffing - this is what gave rise  
> to HTTPS in the first place.

Indeed. I think we're quibbling the definition of "user-selected". To  
me, which clicking on a link is, strictly speaking, the selection of a  
service, doing so in the expectation (and being reassured) that the  
resource is being accessed securely when it isn't, is not an explicit  
choice to avoid end-to-end security.

>>> I think I agree, but what I'm talking about is a proxy inserted  
>>> into the connection twixt client and server without the knowledge  
>>> of either party.
> which happens either because one party made a choice they didn't  
> understand, or because someone cracked the HTTPS stream.

Or because one party made no choice whatsoever - their network  
operator made one for them.

>>> Right. So if the user chose to use a particular service that  
>>> distributes its processing over a network, rather than around a  
>>> particular computer, isn't that also a user decision?

Indeed, but I'm talking about choices that a user may not be making.  
Clicking a link isn't making a choice when the resource accessed via  
that link is modified without your knowledge.

>>>> The user's understanding of the service they have contracted is  
>>>> something like the a content provider's decision to serve  
>>>> different things to different users. It is an interesting topic  
>>>> for market (de-)regulators, but technical guidance for services  
>>>> should be wary of straying into it.

I think I agree here - it's certainly a thorny issue, and it's not  
purely a technical one either. I'm nervous of how we can give advice  
to usefully alert and educate users to issues in a technical document.  
But at the same time, ignoring the problem completely because it's not  
a technical one doesn't seem quite right either...

--
Future Platforms
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
work: www.futureplatforms.com
play: tomhume.org
Received on Wednesday, 4 February 2009 18:34:37 UTC

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