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: Tue, 3 Feb 2009 12:48:15 +0000
Message-Id: <F88A9D75-D19A-4156-A5D1-1DCB0E484BD6@futureplatforms.com>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

To me, there are a few factors which make security implications of  
HTTPS link rewriting more serious:

1. Users are not aware of it when it happens; my mother might enjoy a  
fully-secure connection on her handset on O2, and an insecure one when  
on Vodafone, say; and be both unaware of the difference and unable to  
make an informed decision as to security without understanding the  
underlying models for it. Worse - the handset would likely use typical  
browser mechanisms (e.g. a padlock icon) to reassure mater that she's  
enjoying full security, when this is not in fact the case.

2. Whilst key-loggers introduce similar problems in individual  
clients, the security issue seems amplified by transcoders - in that a  
security issue in a transcoder deployment would put many sessions at  
risk, not one.

3. Some content providers might reasonably expect that by providing  
services over HTTPS, they can be assured of end-to-end security; and  
this does reduce such security.

As you (and I think others) have suggested, specifying data security  
processes or standards might address these to some degree; and  
equally, there are cases in which HTTPS is used when full end-to-end  
security isn't an absolute requirement. But there's no way for a  
content provider to indicate this.

On 3 Feb 2009, at 12:02, Charles McCathieNevile wrote:

> If this seems odd, then please explain the opposite - in what way is  
> it
> not a set of distributed processes communicating with each other?  
> That is
> how all but the most elemental software works. And software like  
> screen
> readers make themselves what Luca is calling a "man in the middle"
> directly intercepting the video stream at times. Yet we don't  
> generally
> see people trying to block this transformation.

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 Tuesday, 3 February 2009 12:49:09 UTC

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