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

I've reviewed the updated entry and greatly appreciate your help
bringing it into conformance with the new template.

My feeling is the two variants of the requirement are for all practical
purposes equivalent:

Variant 1 - Roessler
Web User Agents MUST NOT display bitmaps controlled by Web Content in
areas of the user interface that are intended or commonly used to
communicate trust information to users. 

Variant 2 - McCormick
Web User Agents MUST NOT display bitmaps controlled by Web Content in
areas of the user interface that are commonly expected to be under the
control of the user agent. 

The reason I think these variants seem equivalent is that a significant
number of users assume any part of the UI controlled by the UA (aka
"chrome") can be relied upon for trust information.  Why would I rely on
trust information presented in one area of chrome (e.g., Location Bar)
but not another (e.g., Bookmark List)?  If some parts of chrome are
truly more trustworthy than others, how is this distinction communicated
to users?

Given my position that these variants are semantically equivalent -- or
at least they would be if we defined trustworthy chrome correctly -- I
submit that Variant 2 is the one WSC should adopt because it avoids the
messy problem of defining trustworthy chrome.

If Variant 1 is adopted, I would strong suggest we define exactly what
is meant by "areas of the UI that are intended or commonly used to
communication trust information".  As presently written I feel it is too
vague and open to subjective interpretation.

Thanks, Mike

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Wednesday, June 13, 2007 9:45 AM
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

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#p
review
--
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 19:33:57 UTC