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

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