- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 11 Jun 2007 00:20:52 +0200
- To: michael.mccormick@wellsfargo.com
- Cc: Mary_Ellen_Zurko@notesdev.ibm.com, public-wsc-wg@w3.org, rachna.public@gmail.com
[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