W3C home > Mailing lists > Public > public-wsc-wg@w3.org > June 2008

Re: ACTION-486: Rewrite section 5.4.3

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 11 Jun 2008 21:01:10 +0200
To: Johnathan Nightingale <johnath@mozilla.com>
Cc: W3C WSC W3C WSC Public <public-wsc-wg@w3.org>
Message-ID: <20080611190110.GN272@iCoaster.does-not-exist.org>

Looks good to me.  I've dropped these into the current draft, with
some changes from "TLS-protected resource" to "TLS-secured page".

-- 
Thomas Roessler, W3C  <tlr@w3.org>





On 2008-06-11 14:37:36 -0400, Johnathan Nightingale wrote:
> From: Johnathan Nightingale <johnath@mozilla.com>
> To: W3C WSC W3C WSC Public <public-wsc-wg@w3.org>
> Date: Wed, 11 Jun 2008 14:37:36 -0400
> Subject: ACTION-486: Rewrite section 5.4.3
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> Authentication-Results: mx.google.com; spf=pass (google.com: domain of
> 	public-wsc-wg-request@listhub.w3.org designates 128.30.52.56 as permitted
> 	sender) smtp.mail=public-wsc-wg-request@listhub.w3.org
> Archived-At: <http://www.w3.org/mid/ED675126-072F-4B72-8D11-A49F48C0E220@mozilla.com>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000220, version=1.1.6
> 
>
> As discussed in today's call, the text in section 5.4.3 is difficult for me 
> to make heads or tails of, particularly in terms of claiming conformance for 
> Firefox.  Since others in the group seemed to feel similarly confused, I 
> took an action to re-state what, on the call, appeared to be the consensus 
> goals of this section, despite its current wording.
>
> I propose that section 5.4.3 as it currently exists be removed, and the 
> following text inserted as the new 5.4.3 and (added) 5.4.4.  I tried to 
> provide basic motivation and straightforward conformance language for both 
> issues.
>
> -=-
>
> 5.4.3 Redirection Chains
>
> Page redirection (whether by 302-style http headers, or html/javascript 
> logic) can happen so quickly in some cases that it is possible for UI to 
> appear as though a continuous, secure connection has been maintained, even 
> if navigation between pages has involved redirects over weakly TLS-protected 
> or unsecured http channels.  This can engender false confidence in the 
> integrity and privacy of user data.  Web user agents SHOULD inform users, 
> using an error of class Warning or above (ref 6.4.3, 6.4.4), when navigation 
> between TLS-protected resources involves redirects which travel over weakly 
> TLS-protected, or unsecured http channels.
>
> 5.4.4 Insecure form submission
>
> Users interacting with a strongly TLS-protected resource are likely to 
> develop the impression that information submitted during these interactions 
> will be likewise strongly TLS-protected.  User agents SHOULD warn users, 
> using an error of class Warning or above (ref 6.4.3, 6.4.4), if form 
> submissions from a strongly TLS-protected page are directed to an unsecured 
> channel.
>
> -=-
>
> Cheers,
>
> Johnathan
>
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
>
>
>
>
>
Received on Wednesday, 11 June 2008 19:01:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 11 June 2008 19:01:53 GMT