Re: "Chrome"

These are a good set of questions to use to test the two definitions I 
suggested:

> window chrome -- visual elements used by Desktop browsers or the OS 
> window manager to surround the web page
>
> browser-controlled presentation elements -- any user interface 
> presentation controlled explicitly by the browser and not under direct 
> web page control

Tests below...

Chuck Wade wrote:
> Brad, et al,
>
> You've mapped the user presentation context to issues of trust in a 
> nice, succinct manner. Furthermore, your alternative term, 
> "browser-specific/controlled presentation elements" is a better 
> working definition for what is more glibly referred to as "chrome."
>
> What needs to be added to this discussion is the need to make it clear 
> to the user what part of their display is controlled by the browser 
> (independent of whether or not they trust it), and by the remote web 
> site. Unfortunately, as we've noted many times, the organization of 
> the presentation elements has become confused in ways that hamper a 
> user's ability to differentiate between what the browser put on their 
> screen vs. the web site or sites. The ability for a web site to 
> over-display presentation elements controlled by the browser is one 
> source of problems, but things like "favicons" (or url icons) also 
> confuse the organization of the display for the user (credit to 
> Phillip for repeatedly making this point).
>
> It seems that this issue of clarifying to the user what portion of 
> their display is controlled by what entity is core to usability and 
> user confidence. It also seems that this continues to the elude the 
> industry as the clamor for features overrides concerns for the user's 
> ability to map what's going on. Fundamentally, if average users can't 
> perform this mapping with confidence, then we'll never win this game 
> of trust.
>
> This issue also iterates to the next level. Your trust chain of "user 
> => browser => web site" really extends to multiple "content sites" 
> that interact in ways that can be [very] confusing to the user. While 
> this WSC project can, and should, say something about cordoning off 
> the browser's presentation elements, we should at least think about 
> the problem of the user trying to discriminate which of the many 
> presentation elements on their display represent the site they think 
> they visited, vs. all the other sites that have piggybacked onto this 
> Web session (e.g., advertisers, in-house promotions).
>
> Before jumping to the conclusion that this is definitely out of scope, 
> consider that there are many browser "features" (some plugins, some 
> built-in options) that allow users to block advertisements, pop-ups, 
> flash animations, and other third-party content. This has the 
> important advantage to the user of reducing the web page display to 
> just the elements that truly come from the site identified in the 
> location bar. Imagine, for a moment, a browser that might offer the 
> user the ability to gray out all the elements in a web page that are 
> *not* associated with the site identified in the location bar. 
> Wouldn't this be something that users would value in terms of 
> improving their confidence? (Irrespective of what us technologists or 
> the marketing folks might say?) I don't think it's a stretch to say 
> that the browser options that allow users to constrain content (e.g., 
> popup blockers) are every bit as popular as the options that enrich 
> content (e.g., flash). (Aside, how many users know that there are 
> active, though hidden, controls for a flash object displayed on their 
> screen, but what these controls can do is constrained by the content 
> provider? Should such controls be considered part of somebody's chrome?)
>
> If the ability to manage the content that can be displayed on a screen 
> is important to users, then this will come back to the more 
> fundamental browser design issues, such as how such content controls 
> should be presented to users, and how they know which controls are 
> active at any time. This will bring us back to the issue of "safe 
> browsing," and how a user can know that they're actually in the safe 
> browsing mode, and that the content they see is truly constrained by 
> this mode.
>
> Some browsers and plugins will indicate their current state of 
> operation in the window "chrome" of a browser (i.e., always visible), 
> while others hide their state, perhaps in preference settings. 
> Certainly, the lack of standardization for how these potentially 
> critical indicators are displayed is one of the challenges confronting 
> users and browser designers alike.
>
> Which brings me to some questions for which I have not yet seen 
> definitive answers:
>
>   1. Does the "chrome" include any dialog boxes or other control
>      elements used to configure the browser or control the display
>      context? What about the alternative term
>      "browser-specific/controlled presentation elements"?
The objective was to separate the current concrete window dressing from 
the browser-control semantics.  Given the two definitions I posited, the 
dialog boxes are not "window chrome" as they do not surround the page.  
They are examples of "browser-controlled presentation elements".
>
>   2. What about the menu bar? Here we need to be careful that we don't
>      get caught up in the OS wars.
The menu bar is "window chrome".  Window chrome is a type of 
"browser-controlled presentation element".
>
>   3. Speaking of the OS wars, should we at least consider the
>      relationship of the OS to the browser? After all, the more
>      complete trust relationship is User => OS => Browser => Web. 
I think the user trust relationship is still with the browser, but the 
browser has a dependency on the OS.

Historically, the user has not expected the OS to make any statements 
about network resources and HTTP has been at a layer slightly above the 
OS consideration. 
>      Let's
>      be real, the interaction between the OS and the browser has been a
>      contentious issue of the past, and it's likely to remain so in the
>      future. 
Historically, the OS has largely punted and left security context 
presentation information for network resources to the application.  This 
seems to be changing to some extent with Windows Vista. 
>      Would we be putting our heads in the sand if we ignore
>      this issue? It is the OS that controls the display in the first
>      place, and OS vendors already leverage this point of control
>      within the browser context to their own advantage, but also to the
>      advantage of users.
I think it is a fair question to ask who is responsible for presenting 
security context information -- the browser or the OS.  We may need a 
definition of browser to complete this mix.  As OSes begin to 
incorporate more HTTP and XML rendering into their core capabilities, 
they become browsers. 

However, I think much of our security context consideration may be able 
to remain agnostic to whether the browsing functionality comes from the 
OS or an application.
>   4. Should there be standard conventions for how to display the state
>      of browser content controls within the default window frame
>      "chrome" areas? (e.g., popups currently blocked) Can we keep this
>      from leading to another round of toolbar mania?
I think that is what the group is trying to do.  I'm not convinced that 
it should be withing "window chrome", but certainly we're trying to 
standardize how that information is presented in the "browser-controlled 
presentation elements."
>
>   5. Can any of this be made understandable to users? Aside, I contend
>      that users will make the effort to understand and become facile
>      with what matters to them and their browsing experience, but not
>      necessarily what browser vendors or Web site content developers
>      think should matter to users.
That is clearly the core problem we're trying to solve.
>
>   6. Is there a way to factor out a lot of the confusing knobs, dials,
>      and indicators, and get to some simple "idiot-proofed" controls
>      (analogous to "idiot lights" on an automobile dashboard). Here's
>      where the "safe browsing" mode could come into play--a
>      comprehensible mode that eliminates a lot of the clutter, but
>      establishes confidence in the user that they can  reasonably
>      determine whether or not to trust what's in front of their face.
"Safe browsing" mode is one potential model for representing security 
context information, but not the only one.  I also refer to my earlier 
post, where it appears that the only thing we may really need to 
safeguard is the submission of data.  Having an entire browser mode 
dedicated to making sure that a form submit is secure seems perhaps 
overkill.
>
>   7. Where do we draw the distinction between browser controls (whether
>      or not within the chrome) and controls associated with other
>      content presentation tools within the same Web page? (e.g.,
>      Acrobat, Flash, RealMedia, QuickTime, WM.) How would users like
>      for these controls to be presented? Should we care?
The important point which you make above is that the user needs to 
establish trust to the browser clearly.  Therefore the browser needs to 
clearly differentiate the "browser-controlled presentation elements" 
from any other presentation elements displayed by the web page or any 
plugin.

--Brad
>
>
> Apologies for being so long-winded about a mere definition of terms, 
> but my sense is that the definition of browser chrome is a lot more 
> complicated than any of the traditional interpretations might 
> indicate. We may find that retrofitting usability to the current 
> browser/web-site framework is about as difficult as retrofitting 
> security to an insecure system. In this case, the issues of security 
> and usability are completely intertwined, so the analogy is more than 
> apt.
>
> ...Chuck
> _____________________________
>   Chuck Wade, Principal
>   Interisle Consulting Group
>   +1  508 435-3050  Office
>   +1  508 277-6439  Mobile
>   www.interisle.net
>
>
> Brad Porter wrote:
>>
>> I think the key is that you need to establish the following trust 
>> relationship:
>>
>> user->browser->site
>>
>> The browser can't say anything credible about the site unless the 
>> browser has a trust relationship with the user.  Implicitly, we're 
>> saying that the user can't trust the site without the browser 
>> representing that site.
>>
>> If we were to change terminology, I might say something like 
>> "browser-specified presentation elements" or "browser-controlled 
>> presentation elements" instead of chrome.  This phrasing also 
>> addresses the issue that visual chrome doesn't apply across 
>> modalities or with different accessibility models.  In these cases, 
>> the presentation elements might be audio instead of visual or 
>> accessible via a hot-key or some other mechanism.
>>
>> --Brad
>>
>>
>> Mike Beltzner wrote:
>>>
>>> A couple of definitions I found ..:
>>>
>>> "The interface elements of a browser, or any other program, that 
>>> create the frame around the window that displays pages."
>>>   (cite: 
>>> http://www.chriscassell.net/classes/2001/winter/gdt150/handouts/vocabulary.html) 
>>>
>>>
>>> "The visible graphical interface features of an application are 
>>> sometimes referred to as "chrome". They include graphical elements 
>>> (widgets) that may be used to interact with the program. Common 
>>> widgets are: windows, buttons, menus, and scroll bars. Larger 
>>> widgets, such as windows, usually provide a frame or container for 
>>> the main presentation content such as a web page, email message or 
>>> drawing. Smaller ones usually act as a user-input tool."
>>>   (cite: http://en.wikipedia.org/wiki/User_interface_chrome#GUI_design)
>>>
>>> I think the salient detail is that chrome is what allows the user to 
>>> interact with the browser alone from interacting with the web 
>>> content. Bob's point about the display of chrome being restricted to 
>>> the browser is also good to keep in mind, and relevant for our 
>>> purposes.
>>>
>>> cheers,
>>> mike
>>>
>>> On 12-Feb-07, at 9:44 AM, Bob Pinheiro wrote:
>>>
>>>> I thought the key distinction with regard to "chrome" is that there 
>>>> are certain areas of the browser window that are solely under the 
>>>> control of the browser, and not the website being displayed.  So 
>>>> anything displayed in the "chrome" can be assumed to be coming from 
>>>> the browser itself, and not the website.  However, if some browsers 
>>>> have areas where both the browser and the website can communicate 
>>>> information, that seems to muddy the issue.  Maybe such areas 
>>>> should have a different name, reserving "chrome" for those areas 
>>>> where only the browser can communicate to the user.
>>>>
>>>> At 08:16 AM 2/12/2007, Mary Ellen Zurko wrote:
>>>>
>>>>> During our f2f, the discussion about "chrome - what is it" came up 
>>>>> again. The discussion was part of going over "Poorly defined role 
>>>>> for chrome". It was a divergence at the time, so we decided to 
>>>>> take the discussion to the list. See:
>>>>> http://www.w3.org/2007/01/30-wsc-minutes.html
>>>>> "what is chrome? diaglog boxes should be included"
>>>>>
>>>>> We'll need the definition of Chrome for the Glossary that Tim is 
>>>>> pulling together as well.
>>>>>
>>>>> What I mean to mean by Chrome are the parts of the window that 
>>>>> include information that the User agent/Browser is trying to 
>>>>> communicate to the user, vs the parts where the browser is 
>>>>> (expected to) faithfully represent what the web site/page is 
>>>>> trying to communicate to the user. Some areas in some browsers 
>>>>> currently contain both (for example, the title area including both 
>>>>> the HTML title and browser identity information).
>>>>>
>>>>> Anyone else have a better definition?
>>>>>
>>>>> I also remember people getting fixated on the word. If the word 
>>>>> itself is getting in the way of a concept we consider important, 
>>>>> then we can start using some other word which we can all agree on. 
>>>>> So this might instead be an exercise where we agree on the concept 
>>>>> first, then agree on the word we'll use.
>>>>>
>>>>>
>>>>> [ACTION-132 - Start discussion on mailing list to draw chrome 
>>>>> items out and get analysis completed [on Mary Ellen Zurko - due 
>>>>> 2007-02-13].]
>>>>>
>>>>>           Mez
>>>>>
>>>>> Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>>>>> Lotus/WPLC Security Strategy and Patent Innovation Architect
>>>> ---------------------------------------
>>>> Bob Pinheiro
>>>> FSTC Project Management
>>>> Bob.Pinheiro@FSTC.org
>>>> 1 908-654-1939
>>>
>>>
>>>
>>
>>

Received on Monday, 12 February 2007 18:46:07 UTC