Re: ACTION-208: "Site Identifying Images in Chrome" displayrecommendation

Per ACTION-249, I've updated the Wiki entry [1] to comply with the
template.  I've included two variants of a possible requirement.

1. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/FavIcon#preview
-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2007-06-10 23:47:00 -0500, michael.mccormick@wellsfargo.com wrote:
> From: michael.mccormick@wellsfargo.com
> To: tlr@w3.org
> Cc: Mary_Ellen_Zurko@notesdev.ibm.com, public-wsc-wg@w3.org,
> 	rachna.public@gmail.com
> Date: Sun, 10 Jun 2007 23:47:00 -0500
> Subject: RE: ACTION-208: "Site Identifying Images in Chrome" displayrecommendation
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> Thanks Thomas.  This may prove difficult to discuss via email but for
> now I'll respond inline as best as I can:
> 
> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org] 
> Sent: Sunday, June 10, 2007 5:21 PM
> To: McCormick, Mike
> Cc: Mary_Ellen_Zurko@notesdev.ibm.com; public-wsc-wg@w3.org;
> rachna.public@gmail.com
> Subject: Re: ACTION-208: "Site Identifying Images in Chrome"
> displayrecommendation
> 
> [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.
> 
> *** MIKE: Agreed.  I was too harsh.  Let's reword the Disruption section
> (again).
> 
> 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.
> 
> *** MIKE: Here I must disagree.  The favicon is never useful to identify
> a site because it is completely untrustworthy for that purpose.  Anyone
> who uses favicons to identify sites effectively proves why they're a bad
> idea security-wise.
> 
> - 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.
> 
> *** MIKE: I wish I'd been with you in Dublin.  Since I wasn't, let me
> ask, what was the rationale for restricting the use of favicons only in
> the Location Bar?  It seems to me favicons are dangerous anywhere they
> appear in trusted chrome.
> 
> (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.
> 
> *** MIKE: I included this because I felt W3C might want to encourage
> some follow-on industry work to improve the favicon mechanism and bring
> it into compliance with WSC.  I'm okay with removing it through if that
> is the will of the group.
> 
> 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?  
> 
> *** MIKE: The purpose of the phrase "at this time" is to make clear that
> our concerns are with favicon mechanisms as implemented today, again
> leaving the door open for an improved Favicon 2.0 in future.
>     
>   * 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
> 
> *** MIKE: Fair enough.  Where are we collecting all the out-of-scope
> protocol changes we would like someone to pursue after WSC in order to
> make our recommendations more effective?
> 
> - 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.
> 
> *** MIKE: Indeed.  I'm told there was some lively discussion of my
> favicons proposal (even before the meeting adjourned to the Grafton
> Street pubs :).  Wish I'd been there.
> 
> 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.
> 
> *** MIKE: Now you have it!
> 
> Cheers, Mike
> 
>

Received on Wednesday, 13 June 2007 14:45:34 UTC