Re: "Chrome"

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