Re: Action-146: Starting up a new thread on "future proofing" WSC's recommendations

I think this is incredibly insightful.  I look at the rapid growth of 
voice, mobile, and desktop widgets all being powered by the "browser" 
metaphor without the traditional browser.

The biggest challenge, I see, however, is that the trust relationship 
still goes from user->user agent->content.  So we still need to figure 
out what bits the user can trust and how they're going to get presented.

I think this also brings us back to asking the question -- what actions 
really require security context information?  The only cases I've heard 
so far are as follows:

    1) Establishing that you are submitting your information to the
    party you intended

    2) Establishing that the information you received or are sending is
    "confidential" between you and the third-party

    3) Establishing privilege when a site wants to access "privileged
    resources" outside of the typical sandbox


(arguably #1 is a subproblem of #3)

I'll again observe that I think these can be solved as part of the 
active-task-flow instead of part of the passive-browser-context and 
therefore can be made far more robust and work far better across 
different user agents.

Brad

Chuck Wade wrote:
> Folks,
>
> During today's conference call, I opened my big mouth and introduced 
> some new thoughts about the work of this group. For penance, I've been 
> assigned the task of starting a new thread that will hopefully serve 
> as a constructive dialog on how we can make useful recommendations for 
> improving the ability of users to understand whether or not they 
> should trust their Web interactions--not just for today's browsers and 
> severs--but within the context of an evolved Web where users will use 
> a variety of platforms and applications to interact with an 
> increasingly diverse set of services.
>
> A concern I'd like to voice is that what really matters to users is 
> their ability to establish confidence in their Web /interactions/, not 
> their Web /browser/. This Group's "Notes" document does a commendable 
> job of outlining the problems in presenting security information 
> within the context of a browser, but if the majority of Web 
> interactions in the not-too-distant future involve non-traditional 
> browsers and other Web agents, then we run the risk of recommending 
> improved practices and proposing solutions to last year's technology. 
> By analogy, we could be describing how to make and use better buggy 
> whips, just as the horse is being replaced with an engine.
>
> Note that I'm assuming that these future interactions will still 
> employ the http and https protocols we know and love--they've already 
> withstood the transition from HTML 1.0 through to XML. Continuing with 
> my analogy, we may be replacing some horses, but we'll still be riding 
> on the same roads--potholes and all.
>
> Mind you, I'm not predicting the demise of the venerable Web browser. 
> I anticipate using a browser for everyday Web interactions for many 
> years into the future. However, I am suggesting that we could soon see 
> the majority of Web interactions (at least as measured by transaction 
> volumes) based on non-traditional browsers or applications that are 
> not in any way "browsers" as this term is currently understood. In 
> many cases, Web interactions will move to special-purpose applications 
> that alter the entire user experience. Apple's iTunes application and 
> the way it integrates with their music store is one currently popular 
> example of an evolved Web interaction model. Google Earth is a 
> somewhat more extreme example. [What is the "security experience" for 
> users with these sorts applications?]
>
> At the same time, it is quite likely that the Web is going to rapidly 
> evolve beyond the current "page" model, and become a set of 
> interactive services that blur the distinction between client and 
> server, or page and viewer. Content is clearly becoming more dynamic 
> and more multimedia. While these evolutionary trends will certainly be 
> compelling to most users, there will also be further confusion about 
> what entity a user is interacting with, especially as fraudsters and 
> other n'er-do-wells move to exploit the new and evolved Web.
>
> So, why does any of this matter? Don't we have enough on our plates 
> with trying to clean up security for today's Web browser/server model? 
> Shouldn't we stick to our knitting and deal with the problem at hand? 
> [Shouldn't I stop with all of these metaphors?] While it is tempting 
> to declare that our scope should be constrained to the security 
> "experience" offered by modern browsers, I would like to argue that 
> doing so would be a mistake.
>
> Throughout the evolution of information processing systems, we have 
> consistently introduced new features, capabilities, and services 
> without security baked in, or even considered as a matter of fore 
> thought. Security through hind sight has been the norm. However, to 
> give credit where it's clearly due, early Web browsers and servers may 
> be one of the few examples of where a mass market information service 
> was developed with useful security mechanisms built in. True, there 
> were many mistakes, and the promise of better security has not yet 
> been realized. At the same time, this is the very experience that 
> should be instructing new initiatives to evolve the Web. If we don't 
> carry forward the lessons that have been learned from the past, 
> then.......
>
> To stimulate further dialog along these lines, let me offer some 
> arguments for a broader approach that attempts to anticipate future 
> evolution of the Web:
>
>   1. New applications offer new opportunities to employ better
>      approaches to security usability than can be practically
>      retrofitted to traditional browsers and servers.
>
>   2. The classic browser model has become a constraint on improving the
>      "security experience" for users. Because it has to work in a
>      familiar way, it cannot easily require users to change their
>      approaches.
>
>   3. It is time to rethink the relationship between browsers and the
>      platforms on which they operate. How much better could the
>      security solutions be if vital security functions were
>      incorporated into the platform? Based on the experience this group
>      represents, what useful guidance could we offer to platform
>      developers? Conversely, what could we learn from platform
>      developers? [What would happen if all http/https services moved
>      into the platform?]
>
>   4. Platforms are evolving as well. Not just new OSs, but new hardware
>      form factors, new computational models, and new embedded security
>      functions are all ingredients in an ever more diverse set of
>      platforms. The "one laptop per child" and the "iPhone" are just
>      two examples of platforms that should be forcing radical new
>      thinking about how Web services should be delivered. [We all know
>      this, but shouldn't we actually be addressing the potential role
>      of new platforms in the recommendations we deliver from our 
> mountain?]
>
>   5. It is increasingly important for security context to be carried
>      across multiple applications in a way that is visible and
>      comprehensible to real users. With today's browsers, this actually
>      does happen, but not in ways that most users could figure out
>      what's going on. [Try visiting the W3C site, logging in, and then
>      switching to a different browser and accessing the same
>      pages--there's a lot going on under the covers that depends on
>      your platform and the browsers you use.] What should happen when a
>      user "browses" the world using Google Earth, enters a shopping
>      mall, and then goes to buy something from a merchant that has
>      extended their physical mall presence into cyberspace? [There's a
>      similar scenario for the user that starts out in Second Life.]
>
>   6. With an evolving Web will come evolving threats. Before new
>      applications are introduced, it would be highly advantageous to
>      put forward guidance for how to extend the Web without introducing
>      major new vulnerabilities that open new threats. Here is where our
>      "voices of experience" coupled with the credibility of W3C can
>      influence future outcomes in a positive manner. Just establishing
>      some discipline for how users are presented with security context
>      they can use would be a positive force in shaping the future of
>      the Web.
>
>   7. Security functions like "Basic Auth" started down a useful path,
>      but got hopelessly off track. Can we propose new security
>      functions that not only get it "right," but that could also be
>      consistently offered within all future Web application contexts?
>
>   8. The Web can also be evolved to support more constrained
>      environments, not just glitzy new multimedia flash dances. For
>      example, why does a banking application need to be anything more
>      than a simple interface that operates in a highly constrained, but
>      [hopefully] more secure environment. Can we propose ways to allow
>      the Web to evolve to support such constrained interactions where
>      the client application and server support a fundamentally more
>      secure interaction model that reinforces user trust and
>      confidence? If we were to postulate a "banking widget" sitting on
>      our virtual desktops, what would be the optimal way to present
>      security context to the user?
>
>
> The issues I've raised above are not easily addressed, and they do 
> expose the work of this group to the threat of unconstrained scope 
> creep. At the same time, I contend that these issues will be difficult 
> to avoid, so perhaps we should think about possible frameworks in 
> which we can propose better ways to reinforce user trust in Web 
> interactions--now, and in the near future.
>
> ...Chuck