Re: ACTION-208: "Site Identifying Images in Chrome" display recommendation

[Meta point: I think this is in the critical path for me fulfilling
ACTION-249 in a good way.  I'll proceed to edit along the lines
discussed in Dublin if I don't hear otherwise by EOB Monday.]

Reviewing the "site identifying images in chrome" wiki entry as it
currently stands, here's a bunch of observations.


I find the current "disruptions" text a bit argumentative -- there
is indeed a functional purpose to having "something" in the chrome
that you can drag and drop to bookmark a site; there is no
particular functional purpose to having the appearance of that
something possibly controlled by the attacker.

Also, claiming that anybody who uses a favicon to recognize a site
just proves an anti-pattern, stays a bit at the surface.  There are
at least two related observations:

- In most cases, we're actually not dealing with an attack.  In
  these cases, the favicon (as little as we might like it) is indeed
  useful to identify a site.

- Some systems don't represent minimized windows using an icon
  supplied by the application, but rather through a thumbnail view
  of the page content.  That thumbnail view has all the same nasty
  properties in case of phishing attacks.  I'm not sure if there is
  any useful conclusion from that, but it's maybe worth considering.


Now, to the substance...

Reviewing the current text in the Wiki and the minutes from the
face-to-face [1], I think we have two competing proposals on the
table to deal with site-identifying icons -- and that is without
folding in the various logotype proposals.


Both would be applicable to Web User Agents with the ability to
display bitmap graphics.

The first one is a broad one that would generically declare favicons
obsolete, essentially; this is what's in the wiki:

 Web User Agents MUST NOT display icons controlled by Web
 Content as part of chrome.

(With some more wordsmithing to be done on what chrome means.)


The other one is what we seemed to converge on when we discussed
this at the face-to-face in Edinburgh; I'm inclined to phrase it as
follows:

 Web User Agents MUST separate display of trust information
 from display of bitmaps controlled by Web Content.

This one would need some further explanation and examples as to what
"separate" really means.  One technique would be:

 TECHNIQUE: Web User Agents MUST NOT display a favorite icon
 associated with Web Content through the favicon mechanism
 [REF] in the user interface's Location Bar.

The background text would then go on to explain: The Location Bar is
commonly used to display trust indicators, including the URI string
(see section [REF]) and the common padlock (see section [REF]?).
Displaying site-determined icons in this space creates significant
potential for confusion, as icons displayed in this space are known
to be taken as trust indicators in experiments [REF -- Rachna
mentioned in Dublin that she has a study].

This second variant of the proposal would not cover things such as
window-switching UI widgets, tab titles, desktop icons, and the like
-- all of which are current use cases for favicons.

(Note that the current Wiki entry doesn't include language on the
padlock confusion issue; I'll need to edit that in.)



Going further through the Wiki entry, there's a section starting
"favicons could be made more secure..." and so on.  This goes a bit
into the speculative; I'd rather strike this paragraph from the
document.

Then, in the "specific recommendations", we have:

- Web sites should not incorporate favicons at this time.

  * "at this time" isn't particularly useful.  What conditions is
    this about?  
    
  * Why is this a good idea?  Or even needed?  The text material
    seems to mostly argue about user agents.

  * Applicability would be to Web Content, so this would be a
    separate Good Practice (more so than a requirement, I guess)

-  Web agents should not display favicons at this time.

   * "at this time"?
   
   * see longer discussion above
   
- The underlying protocol for favicon delivery should be made secure
  or be discontinued
  
  * meta-requirement on protocol design; I'd submit that our
    recommendation is the wrong place to discuss this

- Sites desiring chrome branding should use EV certificate logos

  * this sounds like it should go into separate material about EV
    certs and logotypes in general, so we don't need to reiterate it
    in the favicons section


I know that some of this duplicates discussion from the
face-to-face; it's unfortunate, Michael, that you couldn't make it.

Before I make the edits that I owe per ACTION-249, I'd like to hear
your reaction to this discussion, and also to the discussion in the
minutes.


1. http://www.w3.org/2007/05/31-wsc-minutes.html#Site

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





On 2007-06-09 01:37:40 -0500, michael.mccormick@wellsfargo.com wrote:
> From: michael.mccormick@wellsfargo.com
> To: Mary_Ellen_Zurko@notesdev.ibm.com
> Cc: public-wsc-wg@w3.org
> Date: Sat, 9 Jun 2007 01:37:40 -0500
> Subject: RE: ACTION-208: "Site Identifying Images in Chrome" display recommendation
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> X-Archived-At:
>  http://www.w3.org/mid/8A794A6D6932D146B2949441ECFC9D68040A9F29@msgswbmnmsp17.wellsfargo.com
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> Agreed.  I have rewritten the Disruption section accordingly:
> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/FavIcon
>  
> Thanks, Mike
> 
>   _____  
> 
> From: Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com] 
> Sent: Friday, June 08, 2007 7:23 AM
> To: McCormick, Mike
> Cc: public-wsc-wg@w3.org
> Subject: Re: ACTION-208: "Site Identifying Images in Chrome" display recommendation
> 
> 
> 
> "This recommendation addresses the use of site identifying images
> (e.g., logos) in web agent chrome. Specific implementations
> addressed are favicons and certificate logos. The use of site
> identifying images within content (not in chrome) is out of
> scope. " Not out of scope for the WG. And indeed, the "what is a
> secure page" proposal deals with it. So those two aspects of
> these proposals should be aligned (merged up in the editor's
> draft). 
> 
> "For these reasons, favicon use on web sites requiring user trust
> should be considered a security anti-pattern. Favicons undermine
> the web security context display in two ways. First, they appear
> to provide security context but in reality do not. Second, they
> blur the distinction between chrome and content. " I think
> there's a more general statement hiding here. You give all the
> reasons that favicons are a problem. So that anything that had
> those attributes would be a problem. That more general
> recommendation should also be a part of this one. 
> 
> I do think there might be Disruptions in this proposal. The
> Disruptions section is supposed to be for disruptions caused by
> the proposal. 
> 
>           Mez
> 
> Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
> Lotus/WPLC Security Strategy and Patent Innovation Architect
> 
> 
> 
> 
> <michael.mccormick@wellsfargo.com> 
> Sent by: public-wsc-wg-request@w3.org 
> 
> 05/19/2007 03:00 AM 
> 
> To
> <public-wsc-wg@w3.org> 
> cc
> Subject
> ACTION-208: "Site Identifying Images in Chrome" display recommendation
> 
>  
> 
> 
> 
> 
> I drafted a display recommendation (using the template) that can be found at http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/FavIcon <http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/FavIcon>  in satisfaction of my action item, which I propose can now be closed. 
> 
> Michael McCormick, CISSP 
> Lead Architect, Information Security Technology 
> Wells Fargo Bank 
> 255 Second Avenue South 
> MAC N9301-01J 
> Minneapolis MN 55479 
> *      612-667-9227 (desk)             *       612-667-7037 (fax) 
> (> *       612-621-1318 (pager)            *       michael.mccormick@wellsfargo.com <mailto:michael.mccormick@wellsfargo.com>  
> 
> “THESE OPINIONS ARE STRICTLY MY OWN AND NOT NECESSARILY THOSE OF WELLS FARGO" 
> This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation. 
>

Received on Sunday, 10 June 2007 22:21:04 UTC