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

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 Monday, 11 June 2007 04:47:28 UTC