Re: ACTION-209: What is a secure page?

Or fewer and fewer web sites will do it. 

I think either (or both) are possible. 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




Serge Egelman <egelman@cs.cmu.edu> 
05/28/2007 07:19 AM

To
Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
cc
"public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Subject
Re: ACTION-209: What is a secure page?






Right.  I think my original point was, if we're going to recommend doing
this in chrome, it becomes subject to habituation (if the users notice
it at all).  I reiterate my hypothesis that a good percentage of
websites probably have insecure forms on secure pages.

Not that we should be creating recommendations around poor practices.
However, if we write off this poor practice as such, and our indicator
shows up on a large percentage of websites, it suddenly becomes 
irrelevant.

serge

Mary Ellen Zurko wrote:
> 
> Things that could be considered:
> 
> Chrome area, similiar to the yellow "popup blocked" area in IE, perhaps
> reserved, perhaps not (if "not", then it's spoofable, if only used for
> negative, then not useful to spoof, standard issues about user
> attention...). Techniques like that seem much more in keeping with safe
> staging than dialogs.
> 
> It's possible that the proposals around input rituals could be extended
> to all inputs, not just PII. I'd have to refresh myself on our current
> PIIEditorBar proposal as well as Web Wallet to convince myself one way
> or another.
> 
> I'm not saying we should. I'm just saying that if we actually wanted to,
> I do believe there are some alternatives that would be better than
> what's there and better than nothing.
> 
>>
>> So how does one deal with this?  It seems that FF and Opera are already
>> doing all that can be done (some would argue that IE is as well--if 
they
>> show it once and users choose to disable it, the browser has done all
>> that it can, aside from acting against the user's wishes).
>>
>> There's not much more that can be done.  You can't put something into
>> chrome that examines all insecure forms, as I would wager a decent deal
>> of money that the majority of secure websites have forms to insecure
>> pages (e.g. search boxes).  And you can't really rewrite the content to
>> highlight the insecure forms, as the website can also alter the 
content.
>>  Notwithstanding the fact that users can't tell the difference between
>> chrome and content.
>>
>> So what more can really be done besides a popup?
>>
>> serge
>>
>> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>> >
>> > On Tue, 15 May 2007 22:29:30 +0200, Yngve N. Pettersen (Developer 
Opera
>> > Software ASA) <yngve@opera.com> wrote:
>> >
>> >>
>> >> Hello all,
>> >>
>> >> I have just put my proposals about "what a secure page is" on the 
Wiki
>> >>
>> >> http://www.w3.org/2006/WSC/wiki/WhatIsASecurePage
>> >>
>> >> Some may disagree with several of the suggestions, or have doubts
>> >> about them ever being adopted.
>> >
>> >
>> > And yet more bad examples.
>> >
>> >  - Go to the Hilton homepage http://www.hilton.com/
>> >  - Click on reservations in the top toolbar
>> >  - You are taken to a secure page
>> >  - Over on the right hand side there is a "find a hotel" section
>> >  - Fill in city, state, dates etc.
>> >  - Click the "search" button
>> >  - Your query will now be POSTed to an unsecure server.
>> >
>> >
>> > Browser actions:
>> >
>> >  - Opera and FF 1.5 warns about this, the warnings cannot be 
disabled.
>> >  - IE6 only seem to warn when unsecure form submit warning is enabled 
or
>> > the http->https or vice versa dialog is enabled. (these dialogs are
>> > quite likely to be disabled by the user after the first couple of 
times
>> > they have seen it)
>> >
>> > My problem with this form is not that the query is sensitive, it 
isn't
>> > really that sensitive (although I prefer such queries to be secure
>> > anyway), but that it changes from secure to unsecure during form 
submit
>> > without any prior indication to the user.
>> >
>> >
>> > --Sincerely,
>> > Yngve N. Pettersen
>> > 
>> > ********************************************************************
>> > Senior Developer                     Email: yngve@opera.com
>> > Opera Software ASA                   http://www.opera.com/
>> > Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
>> > ********************************************************************
>> >
>> >
>>
>> --
>> /*
>> Serge Egelman
>>
>> PhD Candidate
>> Vice President for External Affairs, Graduate Student Assembly
>> Carnegie Mellon University
>>
>> Legislative Concerns Chair
>> National Association of Graduate-Professional Students
>> */
>>

-- 
/*
Serge Egelman

PhD Candidate
Vice President for External Affairs, Graduate Student Assembly
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
*/