W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007


From: Thomas Roessler <tlr@w3.org>
Date: Sun, 29 Jul 2007 13:17:15 -0400
To: yngve@opera.com
Cc: public-wsc-wg@w3.org
Message-ID: <20070729171715.GA2974@raktajino.does-not-exist.org>


re-reading WhatIsASecurePage more thoroughly, I see a lot of
concerns around, e.g., a series of "insecure" redirects leading to a
secure page.

I wonder if that's the right approach: Generally, I'd expect an
upgrade in security level to be desirable, but a downgrade

I.e., a situation that should be avoided is one in which a "secure" 
page redirects to a pure HTTP resource, that the causes a bunch of
further redirects back to a secure one.

On the other hand, an interaction in which we're just dealing with
plain HTTP, and upgrade very late, sounds far less concerning --
even though it's indeed a situation that creates an attack surface
by enabling attackers to cause redirects to a phishing site instead
of the desired site, which is in fact a pretty bad exposure if you
consider a use case in which a user might be following a bookmark,
and would therefore likely be conditioned to pay even less attention
to indicators than otherwise (habituation).

I wonder, though, if this is really something we can usefully deal
with from the client side.

Thomas Roessler, W3C  <tlr@w3.org>
Received on Sunday, 29 July 2007 17:17:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC