Re: "Chrome"

Even though you said "Ah" and "Except" in a few places, I think we agree 
on all the points below.  The only difference below is I do include the 
Mac menu bar in "window chrome" given I consider it part of the OS 
window manager and therefore it meets the definition I provided.

The piece we're missing is the definition of browser.  Here's my proposal...

    browser -- any combination of services that together provide an
    interactive user experience by performing HTTP and HTTPS fetching,
    markup parsing, and output formatting of content to a user. 

Given this definition, I'm not sure it matters where which piece is 
performing which function.

--Brad

Chuck Wade wrote:
> Brad Porter wrote:
>>
>> 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,
>>>
>>> [snip...]
>>>
>>>   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".
> Ah, but if you use a Mac, the menu bar is OS chrome. Even the 
> application menu elements are under the control of the Mac OS. 
> Different strokes for different folks.
>>>
>>>   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.
> This distinction is getting blurred, and perhaps we should also 
> consider what the optimal assignment of responsibilities should be. 
> For one thing, the certificate trust stores have been moving into the 
> OS realm, and user management of certs and password vaults is 
> increasingly moving out of the browser. To cite one example, the 
> popularity of RoboForm as a means for managing passwords and forms 
> autofill across multiple browsers on the same OS is shifting the focus 
> of user trust to other system modules besides the browser.
>>>      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.
> And also with new versions of the Mac OS and new Linux distros. I 
> brought this point up because it seems that there are some fundamental 
> shifts taking place in what parts of the system manage presentation of 
> security context.
>>>      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.
> I completely agree. However, I think WSC may have to expand it's focus 
> if we are to avoid irrelevance in a changing environment.
>
> By the way, the browser can also be embedded in other applications. As 
> an example, you've been able to use Adobe Acrobat as a browser within 
> a pdf document context for a long time. I've done major web research 
> entirely within Acrobat at times. This capability will probably show 
> up in the next version of Microsoft Office (and it's also part of 
> IBM's Notes). We also see examples of Mozilla's Gecko engine, 
> Konqueror, and Apple's Safari embedded within other application 
> contexts providing full Web browsing capabilities, but within a 
> different user context. Sometimes the users don't even realize they're 
> browsing (e.g., Apple's iTunes Music Store).
>>>   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."
> There may also be important connections to define between the 
> indicators and buttons that are in the "window chrome" with 
> "browser-controlled presentation elements" that extend the browser's 
> ability to interact with the user.
>>>
>>>   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.
> Yep.
>>>
>>>   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.
> For the most part I agree with you, and with the points you made in 
> your earlier post. I referenced the "safe browser mode" to help 
> illustrate the point about reducing complexity. However, I do think 
> there are some issues of trust that relate only to the presentation of 
> information, not just the submission of information. For example, a 
> phraudster might try to convince victims that their 401k accounts had 
> been wiped out as a prelude to getting them to call a telephone number 
> where the nice person will take all their information to "fix" the 
> problem. In general, as people become more reliant on the information 
> they receive through their browsers, the ability to gain confidence in 
> the veracity of both the source and the content will become 
> increasingly important.
>>>
>>>   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.
> Except that most browsers don't do this today, nor do they provide the 
> user with an ability to ascertain what content presentation tools are 
> controlling the display of information on their screens. While 
> seamless integration of various content presentation tools can be 
> useful, it can also be a source of some troubling vulnerabilities.
>>
>> --Brad
>>
> ...Chuck