- From: Tom Hume <Tom.Hume@futureplatforms.com>
- Date: Tue, 7 Oct 2008 14:39:16 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Folks Some thoughts I've drawn together from various threads on the transcoding of HTTPS links: we've had quite a few comments on this so far. My view is that this isn't something which we can condone - and that we should definitely highlight the fact that transcoding HTTPS links breaks end-to-end security and may mean that users can no longer trust a "secure" indication that their browser might give them to the same degree. But ... if it is going to be done nonetheless then what can we do to protect the security needs of both end-users and content providers? End-users should be warned if they are accessing transcoded HTTPS and given a clear message informing them that what they may believe to be end-to-end security isn't - the wording of this is likely to be tricky. I'd say that they should probably be re-reminded of this each time they start a session, and given the chance to opt out (either by accessing a version free from any transcoding, or by not accessing the resource at all). This would presumably involve injecting content into the exchange between phone and server at some point. Content providers must be able to insist on security by using the no- transform directive to prevent any transformation of their content. They could also use the Via: header to detect possible transcoding (presuming this Via: header has been added and hasn't been stripped out). I'd imagine that most CPs who insist on security will implement no-transform, but it's also reasonable to suggest that CPs don't use HTTPS unnecessarily. I'd note there's no middle ground by which a content provider can say "transcode my content, but preserve my need for security". On this last point, Jo has rightly pointed out that this would lead to an inconsistent experience, but if there's value in these secure services (e.g. banking) I think users might accept this. In fact I've heard from a UK bank that they have customers accessing their full-web version and putting up with a dreadful experience on mobile devices already. Similarly, users should be warned of expired or invalid server certificates that the transcoder receives from an origin server. Francois has also noted the topic of channel bindings (RFC5056) will need discussion with the TLS working group. Tom -- Future Platforms Ltd e: Tom.Hume@futureplatforms.com t: +44 (0) 1273 819038 m: +44 (0) 7971 781422 company: www.futureplatforms.com personal: tomhume.org
Received on Tuesday, 7 October 2008 13:39:54 UTC