A Universal-Design review of the Web Security Context Approach.

With respect to version:
http://www.w3.org/TR/2007/WD-wsc-usecases-20070302/
prepared by:
Al Gilman

Executive Summary

Welcome.

It is so good to see this activity underway.  Internet users and people with disabilities especially have been suffering without good human-engineered communication of security realities.  The internet has definitely changed the landscape for trust and security in business dealings by consumers.  The opening up of access to many offerors is beneficial.  The opening up of inboxes to an equal myriad of spammers is not.  Somehow we need to tame the new realities with a new way of communicating the trustworthiness of contexts within Web use.

Layer your answer: model and view.

People with disabilities are going to need to mess with the carefully-honed presentation that you figure out.  For a case history on security measures that are too presentation-dependent, see our CAPTCHA Note.  To keep your progress from raising higher the digital divide of disavantage for the disabled, you really need to make your answer a one-two punch: clearly define your model of all pertinent decisions and evidence, in a way that it could be processed by programs that reformulate the presentation, and not limited to the projection that you recommend be routinely presented to users with the usual sort of delivery context.  Then do go ahead and articulate good practice as to how to infiltrate the Web user experience with the security aspect of [OLTP] distance operations.  But clearly articulate the caveat that this presentation is only known good within some (hopefully parametrized) neighborhood of "the usual situation." Note that, while not detailing how, users with atypical delivery contexts will a) do better with a different presentation and b) do best with different slices of the total available information.

General Usability is not enough; neither for security information nor for disability access.

Security information deals with context properties that are benign most of the time and occasionally need the user to pay attention to them.  When they need attention, it is because the consequences are potentially serious.  But this happens infrequently.  This is a characteristic of safety and security domains.  People are generally rational actors where the odds are less skewed than roughly 20:1.  But for safety and security, we fervently intend to keep the odds more skewed than 20:1, to ensure that the bad situations are the case much less likely than 5% of the time!  This colors the practice of mixed initiative interfaces as regards the security aspect, and general usability is too colored by more frequent, less critical user actions to be an adequate guide to the design, here.

The recommended remedies for these gaps are:

Security and safety benchmarking
Tap Human Factors expertise from safety-critical domains such as the U.S. Food and Drug Administration.
Draw on techniques and strategies that reflect best current practice in safety and security applications.
Universal Design
Tap experties from people who train users of Assistive Technology
 Draw on technologies and Standards developed with strong Universal Design input such as the Universal Remote Console framework.

Blow-by-blow remarks

These are in document order, mostly.  A few topics have been pulled together.  But they're in a flat, arbitrarily numbered list and not indented per the ToC.

  1. Charter retains authority  
    where it says (in the Abstract)
    This Note will specify the goals for the Web Security Context Working Group.
    please consider
    This Note will refine the objectives for the Web Security Context deliverables. 
    Why? 
    The Charter remains the authoritative source for goals.  This Note does not supercede it in that role.
  2. Formal studies don't cover disability access adequately, use experts too 
    where it says in 2.1 Document the status quo:
    The Working Group will catalog existing presentation of security
       information and corresponding user interpretations reported in user
       studies.
    please consider
    You can't limit the user interpretations that you integrate into your data to formal studies.  Formal studies are often not available that cover people with disability-adapted delivery contexts.  You need to open the gates to allow for the advice of experts and some anecdotal experience from users in building this reference base of experience.
    Why? 
    Most studies that attempt to test for statistical significance don't have the numbers of people with ability diversity to control for that or even let the experience of people with disabilities count much.  So weaker forms of evidence than formal studies have to be relied on.
  3. information overload/underload -- no oneSizeFitsAll 
    where it says, in 2.2 Relevance of security information
       The Working Group will analyze common use cases to determine what
       security information a user requires to proceed safely and recommend
       security information that should, or should not, be presented in
       each case.
    please consider
    While GUI users rarely perturb the presentation decisions of the web author, Screen reader users commonly do use verbosity settings in their user environment.  So the presumption must be that the good practice this Working Group decides on as to "how much to say when" is in fact only competent for user interface modes and conditions similar to the predominant delivery context of web users.  It's not universal.  Yes, it's good to get more consistency in following this good practice where it fits, but recognize the limits of the goodness of this practice and don't think that this goodness extrapolates across all Web delivery contexts.  For that reason, the function/performance model of the security aspect needs to be articulated separately and independently from the good practice binding for presentation of those functions with the desired comprehension and annoyance performance characteristics in the nominal delivery context.  In particular, 10.1.8 "Provide explanations ..." shows you realize that the information needs to be there in support of a mixed-initiative, variable-level-of-detail user experience.  All the available information should be considered 'conditonal content' of the dialog state as contemplated by UAAG 1.0, Guideline 2.  So while the WSC deliverables may well not discuss *how* to present all this information, *some* way to access all this information is a requirement of the UAAG guideline.
  4. presentation norms -- no oneSizeFitsAll 
    where it says, in 2.3 Consistent presentation of security information
       The Working Group will recommend a set of terms, indicators and
       metaphors for consistent presentation of security information to
       users, across all web user agents. For each of these items, the
       Working Group will describe the intended user interpretation, as
       well as safe actions the user may respond with in common use cases.
    please consider
    The desired user interpretation of decisions and evidence are fundamental; this belongs in the model.  It should not be limited to the 'normal mode' dialog that is in the projection of the full model that is discussed above.  The presentation suggestions may be limited to the 'normal mode' projection.  But what the user should understand if they drill down deeper or skim more lightly should be covered, not limited to the suggested summary dialog.  Yes, you want to introduce some terms and icons and the like whose consistent use will enhance recognition of security information when it crosses the user's bow.  But these are not the only prosodic tools that should be used to convey this role in the web-dialog scene or world-let.
    Why? 
    In consideration of the diverse presentation and actuation bindings that are required so that people with disabilities are afforded access to information devices and services, realize that it is essential to define the intended interpretation, which is of broad applicability, and then under specified modality conditions indicate suggested representations.
  5. qualify your interrupts 
    where it says, in 2.4 User awareness of security information
      The Working Group will recommend presentation techniques that
       integrate the consumption of security information by the user into
       the normal browsing workflow. Presenting security information in a
       way that is typically ignored by the user is of little value.
    please consider
    Yes.  The WAI-ARIA technologies are targeted to bring into the fold of accessible web content newer, more integrated high-usability interaction gestures (such as transient flyouts for information or action), as opposed to older gestures such as loading a whole new page or launching a popup dialog.  We should work together. And yes, you sometimes have to get the user's attention.  But on the other hand there are real "boy crying wolf" problems if you contend too hard for the user's attention.  
    Why? 
    There is a rather unruly free-for-all going on out there vying for the Web wanderer's attention.  How do you get the user's appropriate attention?  In part by not seeking it unnecessarily.  I know you are addressing this in part under 2.2.  But it also goes for how you blend the security message into the flow vs. distinguish it so that it is recognized for what it is.  All presentation-based distinctions (2.3) are subject to imitative spoofing attacks.  The communication of a "continuing all clear" security status should be something the user is likely to ignore.  Because it doesn't represent a change from what the user has internalized about their dialog context, nor anything that the user needs to do something about.  The trick is to have the user's field of focus infiltrated with rationally-chosen gestures of graded 'initiative-grabbing' quality for the communication of different hazard or reassurance levels in the security context.  Contemporary rich-interaction Web and installed applications afford a greater variety of such gestures with more subtle variation in attention- or initiative-grabbing quality.  Yes, we want to get with the program in this regard.
  6. no safe haven in presentation space
    where it says, in 2.5 Reliable presentation of security information
       The Working Group will recommend presentation techniques that
       mitigate deceptive imitation, or hiding, of the user agent's
       presentation of security information.
    where it says, in 2.7 Best practices for other media
       The Working Group will provide best practice guidelines for
       other media to follow so as not to undermine the presentation of
       security information on the web.
    please consider
    This part of the strategy seems particularly weak.  Techniques to ascertain the actual presentation of [e.g. DOM objects] is sought by the WAI.  Techniques to query the delivery context are under development by the Device Independence [now Ubiquitous Web Applications] Working Group.  You should think of querying the delivery context for evidence of spoofing 'security indicating' presentation as one of the tools in your deployment strategy.  Likewise, making it easy for the user to exercise a faint twitch of skepticism with what seems to them a lightweight gesture, but raises the sensitivity of security-information-filtering -- that is a closed-loop, mixed-initiative way to move the performance curve of security failures vs. user nuisance.  Also, you should consider introducing practices which are not widely used now but are up and running and working in practice. What if the user gets a page with some protected content and some that was transmitted in unprotected HTTP.  The user doesn't know what in the page is of what category.  Suppose at this point they could by a flick of the hotkey send the challenge "can you send me that offer in a signed document?"  This relies on PKI that is somewhere in the SSL stack, and the server won't have to bear the burden all the time.  When a user is at all concerned, the ethical merchant could want to invest the extra cycles for the cryptography.  In other words, readily achievable changes in technology deployment should not be altogether off the table.
    Why? 
    It seems unlikely that you can limit yourselves to currently-widely adopted technology and not find that any presentation-property syndrome that you select (whether of placement, coloration or language) is vulnerable to highly effective spoofing attacks.  Likewise the appeal to other media to stay out of your protected zone is not likely to be successful unless a duly constituted panel representing all stakeholders decides the allocated reserved presentations.
  7. cooperate with WAI-ARIA 'politeness' of live regions in your quest for assured presentation 
    where it says, 2.5 Reliable presentation of security information
       The Working Group will recommend presentation techniques that
       mitigate deceptive imitation, or hiding, of the user agent's
       presentation of security information.
    please consider
    One of the aspects of verbosity control in some delivery contexts adapted for people with disabilities is the filtering and buffering of events.  In the WAI-ARIA
    specifications, we have introduces values of the @live attribute that denote
    politeness, or the urgency with which the user's attention should be given to
    this event.  You have a similar need with yet more authority, in a way.  It would be great
    if we had event politeness wired into the backplane and we could piggyback
    our functionality for  the access API bindings on top of your functionality for
  8. Drill-down access to all security information is not 'nice,' it's required (by UAAG 1.0). 
    where it says, in (non-goals) 3.1 Presentation of all security information
       Access to security information beyond what is available through the
       recommended presentation may be desireable in many scenarios, such
       as debugging. User agents are encouraged to provide this access, but
       in a way that does not interfere with the recommended presentation.
    you must change
    This statement is too weak.  Mention and link the fact that access to all this information is required by UAAG 1.0, Guideline 2.
    Why? 
    The User Agent Accessibility Guidelines 1.0 is already a Recommendation.  The current work is not chartered to undercut its requirements.  Don't re-invent this requirement wrong; just pass through the relevent authoritatve requirement. 
  9. limited guidance on presentation OK 
    where it says, in (non-goals) 3.1 Presentation of all security information
    This Working Group does not aim to recommend a
       presentation for all of this information.
    Fine.
    But suggestions as to nominal and optional actions to get beyond the short and sweet should be considered by the Group. Further, it is not clear that you should not, for accessibility, provide one nominal (technical report-like) browsable tree structure covering this information; similar to the operation of the Table of Navigation in the Standard Digital Talking Book.  This is not a recommended presentation, it is a structure enabling structured access in diverse presentations.  This assured structure affords one consistent way to explain "where am I" in the course of pursuing more information about the security aspect of the current browse context.
  10. Re: 3.2 Non-HTTP Web interactions 
    Drop this sub-section.  4.1 says it better and says everything you need to say.  Less is more.
  11. don't disable assistive technology 
    where it says, in 4.2 User agents
       Use cases considered by this Working Group must involve a web user
       agent, operated by a human user.
    where it says, in 5.3 Security context information for consumption by automated agent
    The Working Group will only consider Web interactions that include a human user. Situations in which all security relevant information is consumed and acted upon my automated agents are out of scope.
    you must change
    The latter statement is incompatible with standard accessibility requirements, in particularly the W3C Recommendation on User Agent Accessibility Guidelines.  Please review UAAG 1.0, Guideline 6.  On the client side the user must have the option to employ automated assistance that accesses either the W3C DOM or a platform-defined accessibility API.  The machinability of the security information (information characterizing the security aspect of the user's current browse context) is a matter of importance to people with disabilities, and must not be neglected.
    where it says, in  4.4 Third-party recommendation
    The recommendations of certificate authorities,
       visited web sites or reputation services integrated into the user
       agent are in scope for this Working Group.
    please consider 
     The architecture needs to support reputation services integrated with the AT as well as integrated with the base browser.
    Why? 
    People with disabilities who use heavy-duty Assistive Technology such as a screen reader, voice command software, or on-screen-keyboard for switch input management, will find the Assistive Technology a more natural  bundle host for recommendation-service access funtions, as opposed to the base browser.
  12. beyond 'who' (some day) 
    where it says, in 4.3 Entity identification
    Recommending a presentation for these
       designators that helps the user recognize which entity they are
       currently conversing with, and when they are switching to a
       different entity, is a primary concern of this Working Group.
    please consider
    The likely shape of a better world of trust includes the terms of the engagement beyond just 'who.'  Absolutely, the state of what works today is limited to "who" am I talking to.
    And DNS domains are about as scientific a 'who' as users ever resolve in their fuzzy brains, by way of entities that are not human individuals.
    On the other hand, there is still a lot of dissatisfaction from consumers about organizations taking information disclosed for a finite purpose and redistributing it beyond what the user understood as the purpose of that disclosure.  So the group should be aware of contemporary work to model trust decisions in terms of contextual integrity where the parameteters of a context desiring integrity are the defining characteristics of shared tasks as well as who is in or out of the circle of the conversation.
    please consider
    attribute certificates in the picture, eventually (bearer is known to me and assertion/attribute is true about said bearer).  User can provide a voucher for certified quality, not requiring disclosure of user's identity.
    Why? 
    The parking meter needs to know you are a qualifying individual to use disabled parking spots, but it does not need to know exactly who you are.  There are, in the best of all possible worlds, many correlates for this in the world of B2C transactions.  So while a clear communication of "who is in the scene, and who am I conversing with?" is the name of the game for now, the total picture in the long term may use attribute certificates as well as identity certificates.
  13. full legal entity identification (is a must) 
    where it says, in 4.3 Entity Identification
       designators that helps the user recognize which entity they are currently conversing with
    please consider
    If the user can't readily drill down and get a fully-qualified answer to "who do I sue?" you are wasting your breath.  The fact that the user could, in principle, start an independent, un-prompted browse through WhoIs does not meet this requirement.
    Why? 
    Business runs on recourse.  The best commercial practice is not to get it right; but to refund on dissatisfaction.  You can't rewrite this aspect of the climate of values that bear on the small domain of transactions you are working on.
  14. widely deployed baseline, yes; usage and presentation, yes 
    where it says, in 5.4 New security information
    Recommendations will only
       be made for the presentation of currently deployed security
       information.
    please consider
    You will, per goal 2.6, be making recommendations as to how to use the identified, widely deployed technologies; as well as how to present the information that results. You address this in the stated goal, but this statement appears to contradict that one.  Don't leave the reader confused; assert both usage and presentation here.
    Why? 
    The security information that is available will depend on appropriate use of the tech base.  Your recommendations need to spell out the technology utilization that will make necessary information available and not just how to present it when it's there.
    please consider
    We need your expertise applied to identifying "areas for future work"
    in addition to this scope.  I understand that you do not plan to design
    presentation innovations predicated on model innovations.  That's
    appropriate risk management.  But you need to publish the gaps in the
    "currently deployed techbase" as well to foster migration to a higher
    and better state of de_jure as well as de_facto Web security.
  15. define extension interface for content-scanning tools 
    where it says, in 5.5 Content based detection
    The Working Group will not recommend any checks on
       the content served by web sites.
    please consider
    I don't think that you mean people shouldn't check signatures on signed
    content.  What I think that you mean is that the filter queries or trip thresholds
    for statistical techniques such as you discuss will not be published by the group.

    You should consider providing a programmatic interface (perhaps a hypothesis lattice compatible with what a voice recognizer looks like in EMMA) for such tools to contribute to rational decision making about when to raise a warning, and in addition an interface where they can contribute message-content to the security infoset.
    Why? 
    The free-content areas drive trust.  Confidence schemes work in this domain.  So there is an enduring value-added niche for such techniques.  The group should seek to define interfaces whereby third-party software can contribute its findings to the rollup summarized by your recommended presentation.  Otherwise we will continue with the plethora of security helpers waving plackards in our faces.
  16. platform and browser security out of scope - NOT 
    where it says, in 5.6 and 5.7
    (out of scope)
    please consider
    make a greater emphasis on the semantic model of the information; integrated with information from these other sources and presented in platform-appropriate ways.
    Why? 
    There is a strong conflict between this scope restriction and the points raised in 10.1.2, 10.1.6 etc.  The user does not want to, and we don't want them to need to, sub-divide the security information this finely.  The user also wants to extend trust to software in descending order of trustworthiness.  So the OS and browser, in the present order of things, have priority in defining what terse messages merit user attention and how to indicate these.  Integration with the web browse realities means integrating security information from the web application with security information from the OS, [third party security monitor], browser, [browser plugin], and then the page.  If you can't make common cause with these other value-added players in the security situation, you have blown your opportunity to connect with a model the user can generally grok. 
    please consider
    there is an analogy in terms of web pages respecting the system presentation defaults when the user invokes High Contrast Mode.  These are presentation preferences that should be global across the desktop, and the presentation and qualification of messages claiming to speak about security needs to respect this pecking order, too.
  17. trust in browser password cache needs to be better justified 
    where it says, in 8.4 Password management
    (better to let browser keep it)
    please consider
    You have in effect zeroed out the hazard raised by exploits against the OS and browser.  The bald assertion that it's better to minimize re-entry of passwords on repeated visits is thus not credible, because it is patently biased.
    Why? 
    Presently, I let the Apple OS keychain keep passwords for me; else not.  This key wallet is explained as encrypted and this OS has a good track record.  If you want to represent the user's security, you have to include all threats in presenting a balanced picture of good and bad.  If then you want the user to use the browser as a web-password safe, you need to make that case more convincingly than the present appeal to convenience, or avoiding spoofing risk.  Don't substitute a browser security hole for a user security hole.  Fix the problem.
  18. present web security is not good enough; even 'though fixing that is out of scope for this deliverable
    where it says, in 8 Merits of the status quo and 9 Problems with the status quo
    (impression is that the security of the Web is OK, it's just the user is gullible and ill informed)
    please consider
    recognize that there are defects in the platform, say that this deliverable is limited to boosting understanding at the user-browser connection.  Collect and document (even in a companion note) the things you would rather have done but didn't because the platform technology is not as widely deployed as you feel you need.
    Why? 
    Just because this deliverable is going to try to improve things at the cognitive connection between the browser and the user, don't pretend that that's the only problem left to fix.  For example, present practice is to offer the user a printed hardcopy for their records, not a fully machinable data record.  This is a violation of what ought to be basic business rights of the consumer.  The merchants claim that the user can't be trusted to secure these data.  But they don't tell the user that.  They use their wiles to keep the user ignorant of what the could have, and should have, had access to.  That needs to be laid at the door of the Operating System as a defect in user support, not blown by with "best current practice is good enough."   While this is presented as a matter of general consumer defence, it becomes critical for people with certain disabilities where having your personal-business office in a personal computer is the only way to be able to independently conduct your personal business, not just a convenience.  One shouldn't have to pay web merchants through a credit card in order to import the results into Quicken, for example.  And you should be able to import the full, itemized invoice, not just the bottom line.
  19. distinguished Chrome is not the answer 
    where it says, in 9.1 Poorly defined area for chrome
    (user should recognize what information is from browser and not page)
    must change
    The present definition for the chrome is layout-wise.  Change to "the representation through which the user interacts with the browser itself, as distinct from the web content accessed."  Compare with the language in UAAG 1.0, Guideline 1.
    please consider
    Think again.  You are asking the user to make crisp distinctions where they don't want to, and we don't want them to need to.  The chrome represents functionality that, in the way the user recalls it, doesn't change from page to page.  What you use frequently, you want to bring from recall memory and you don't want display capability wasted on tickling your recognition memory for these things.  The innovations are strongly confined inside the page.  So it's rational for the chrome to be a wallflower.  And it's not just the chrome.  The GUI web presents the user with lots of information that they ignore.  The only problem is that what they ignore and what they notice varies from user visit to user visit.  The user doesn't distinguish page content that doesn't get their attention from chrome that doesn't get their attention because, well, frankly, their attention is elsewhere.  So asking them to split hairs among what they don't care about is a futile approach.
    please consider
    Review the relationship of sounds to events and ShowSounds to the critical job of  attention-getting on event.  Different modality mixes have working BCP solutions to this problem and they are different, based on the modality mix.
    Why? 
    audio is more atomic than is graphics; it's harder to be out of earshot than to be out of the visual focus.  On the other hand, it's not always available.
    please consider
    Design the event information (filtering, compression to friendly terse gestures) on the basis of a VoiceXML dialog.  Then abstract to SCXML for flexi-modal presentation.
    Why?
    You will note that screen readers say 'link' when a hyperlink is encountered.  That is to say, some of the dialog-situation information that is conveyed with (status) presentation properties (color, underline) in the GUI presentation is spelled out, articulated in language on-transition events, for the audio presentation.  Designing for a voice dialog, and backing all messages with at least a "say it in a sentence" [if longer] backup will improve your coverage of events the user needs to understand, and can be pruned for the default GUI presentation.  Spelling out both a status and an events view of the process will both improve the quality of your work and make repurposing the the presentation go better.
    please consider
    I want to return to the matter of High Contrast mode.  The reason you are going to have trouble seeking a remedy within the confines of present Web technology is illustrated by the similarity between two functions that are attempting to make the browse experience user-centric and accountable to the user's interest: security and accessibility.  The Web technology of today is characterized by the CSS cascade rule that local rules trump global rules.  This is effective in making point and click operation efficient/easy, but not stable/secure/accessible.  What we are up against is a re-factorization of the user-web engagement into aspects, where there needs to be better support for the stability of the security aspect (and the presentation-adaptation aspect, as well).  For the purposes of information integrity assurance, we can't let the local escape from global discipline.  But that's a change from the techbase.  With the ascendancy of Web Applications (rapidly rising market share w.r.t. installed) you can't just retreat into "what the browser should do."  There has to be a rationalized and enforced continuity between what happens in OS, [AT], browser,[plugin], webApp layers.
  20. benchmarking success -- it's out there
    where it says, in 10 Process
    There are no worked examples of
       standards of usable security to emulate.
    Whoa! think again

    Credit care and debit card operations at groceries, along with RFID based gasoline purchase tokens are all existence proofs of successful tradeoffs between usability and security.

    You need to note "what works" that is "what secure+usable systems are there as close to the targeted domain of Web commerce as we can get?" and not just look inside a narrow definition of that domain and say "there are none."

    Benchmark the closest approaches between the domain of successful applications and your desired target domain.  Don't fail to do this.

  21. augment general usability wisdom because you are operating on a fringe (as is WAI) 
    where it says, in 10.1 Reliance on general usability expertise
    These aims are also a prerequisite for
       usable security. Listed below are design principles, drawn from the
       research literature, recognized by the Working Group as relevant to
       usable security.
    please consider

    General usability wisdom is necessary, but not sufficient.  Neither for accessibility, nor for the security aspect of the browsing experience.

    Specifically seek expertise related to usability under
    adapted-delivery-context conditions such as are used by people
    with disabilities.  General usability expertise is not sufficient to
    assure usability that is robust in the face of variations in user ability and
    situation.  Take specific steps to broaden the base in
    usability-related expertise that you tap as regards diversity in user
    ability and situation.  'Ability' means tap assistive technology trainers
    and Rehabilitation Engineers.  'Situation' means tap the resources
    of the Ubiquitous Web Initiative.
    Why? 
    Security operates outside the sweet spot of usability.  Safety and security have operating points where the likelihood of the downside is unusually small and the significance of the downside is unusually large.  For this reason it's incumbent to benchmark what works in safety and security, and not just usability, and especially not just HCI usability, in the small.  Likewise, robust usability for people with disabilities can be achieved through universal design, but it takes structuring the query; just looking for anything that matches the epithet 'usability' will not assure you of success.
  22. user understanding is where it's at 
    where it says, in 10.1.2 Conceptual model
       A user will develop a personal model of what something does and how
       it works. The user interface should [...] ensure that the actual and perceived
       state of the system are consistent.
    Yes, yes, yes.
    this is the root of all your requirements; adjust the rest where they get in the way
  23. realism is not universal, nor does ordinariness befit exceptional communications 
    where it says, in 10.1.3 Match between system and the real world
       The system should speak the users' language, with words, phrases and
       concepts familiar to the user, rather than system-oriented terms.
       Follow real-world conventions, making information appear in a
       natural and logical order
    please consider
    It is easy for those locked in bitmapped-display or video presentation modalities to get carried away with this.  To the detriment of access by people with disabilities.

    For machine personality, cartoon presentation is more suitable and less disquieting to users than trompe-l'oeil verisimilitude.

    Verisimilitude is a tool that can always be spoofed.  The more you rely on real-world-liness, the harder it is to draw a sandbox around your presentation cues and keep others from re-using them to malign intent.

    Poison warnings and European road signs use heavily symbolized presentation.  Now I, as a U.S. habitue, find this in Germany to be overdone.  But verisimilitude is an easy way to optimize the behavior at the center of the demographic hill and drive it down at the edges.

    Why? 

    People with disabilities will always have to use the content in transcodes of the author's putative presentation.  So be sure to afford both a rigorous model, no matter how code-geeky, as the foundation for what you think (based on testing with  too-central-tendency a sample) is a usable design for a dialog.
    please consider
    the users bring diverse levels of understanding as well as different modalities of access, so the system can't rely entirely on familiarity of presentation.  Thus the system should support mixed-initiative adjustment of the level of 'partial understanding' that is exposed.  You have two performance goals that are in conflict, here:  a) does the user understand what you are trying to tell her? b) does she trust that you have told her the whole truth and nothing but the truth?
    please consider
    the history of 'friendly messages' is littered with the wrecks of things that only hide what the user needs to know.  In one place you inveigh against codes such as "403: forbidden".  On the other hand, this is the only touchstone of "ground truth" that is available cross-browser and cross-platform today.  Don't let it go.  Just as the UAAG supports "source view" as one option the user should have; likewise in the "access to all conditional content" the verbatim evidence from e.g. protocol messages should be an available option.
  24. habit is little help, here 
    where it says, in 10.1.4 Habit formation
       Persistent use of any interface will cause the user to develop
       habits. A user interface should leverage habit formation to shape
       the user's workflow
    please consider
    you are dealing in exceptional situations; can't rely on habit to deal effectively with threats, unless you want to make disaster habitual.  Why do we hold fire drills?  Not because people are going to make a habit of using the stairs for exit, but precisely because they don't.  They need to have things within their recall that are beyond the habitual.  That's the performance point where we are working, here.
    please consider 
    Model and prioritize the full security infoset and actions.
    Recommend good practice as to what to engage the user with and when
    predicated on articulated assumptions of a default delivery context.
    The Screen Reader (for example) and not the Working Group
    has enough knowledge of the user experience and habits to make
    appropriate presentation-pruning and presentation-effect-binding decisions.


  25. qualify your interrupts; communicate subliminally always and through the focus rarely. 
    where it says, in 10.1.5 Single locus of attention
       A user has only a single locus of attention, a feature or an object
       in the physical world, or an idea, about which they are intently and
       actively thinking. Humans ignore things that aren't their current
       locus of attention. The user's locus of attention is only held in
       short term memory and so will be quickly forgotten once their
       attention shifts.
    please consider

    This paragraph sounds as though the security status should be contending for the user's attention along with their main-line task.  This could lead to mis-design.


    This principle is likely to mislead the design if not taken with a large grain of salt.  The point here is that the comfort level of the user with the current context is typically much more unconscious than is their concept of what they are focused on.  Humans react subliminally to stylistic effects that connote changes in context or context continuity in a way that suffuses many of these narrow 'loci of attention.'


    You could be about to throw the baby out with the bathwater.  Many in the Web think that interactive behavior and text effects such as color and underline are 'presentation' that is disjoint from 'content.'  But nothing could be farther from the Web truth.  Color or underline subliminally communicates what is clickable to the visual user, and clickability is essential to the user's concept of web browsing. the web would be a laboratory artifact still if this closure of the interaction cycle through style and behavior weren't in place.  And it works without the user ever focusing on it.  It plays into pre-focus scanning behavior.


    You have amply demonstrated that just like clickability, trustworthiness is something that users judge subliminally.  Our difficult task is in presenting a trickle of nuisance events (small enough so they don't decide it's the boy crying wolf) that will get them to exercise a modicum more skepticism in the nick of time.

    please consider
    event sounds and ShowSounds, introduced before.
  26. simplicity is in the [diverse] world of the user 
    where it says, in 10.1.6 Aesthetic and minimalist design
    Dialogues should not contain information which is irrelevant or
       rarely needed. Every extra unit of information in a dialogue
       competes with the relevant units of information and diminishes their
       relative visibility
    please consider
    presentation effects that communicate subliminally are not subject to quite the same contention as is, say, the collection of objects in a popup.  True, there can be too many of them.  But for a finite number, they tend to play nice together.  Note also that best current practice uses combo boxes at times where the diversity of method afforded adds more than it subtracts.
    please consider
    same old -- layer the answer by model then view
    The Working Group is competent to state what the user needs to understand, and what the user has available to help them understand (including all available) and should spell those out independent of presentation advice or conventions.  Then, in a second layer, suggest what makes sense to present under stated nominal conditions, and how. 
    Why? 
    Under adaptive conditions, there is no way for the experts in this group to a_priori know how much the security infoset should be filtered, or for that matter what constitutes a "friendly message" corresponding to a "403: forbidden."
  27. challenge and recover are essential; one presentation fits all -NOT 
    where it says, in 10.1.7 Help users recognize, diagnose, and recover from errors
       Error messages should be expressed in plain language (no codes),
       precisely indicate the problem, and constructively suggest a
       solution
    please consider
    model the system-driven forward path of the browse dialog and exception- and user-initiated digressions in UML/SCXML.  Document recovery path options in the model.  Then slice and style what you will for stated nominal conditions.
    Why? 
    You simply can't do all those things at once for the breadth of the disabled population.  The literal codes of the protocol messages are the only way to be fully precise.  Plain language is dependent on the language skills of the user.   What the author thinks is a constructive suggestion as to a resolution is frequently a bad choice when operating through an adapted delivery context.  The full model needs to be documented and shared with AT so that appropriate decisions can be made about these things.  Yes, the author (and WG) *should* propose what they *think* is good presentation and recovery paths.  OTOH they need to know that they will be wrong about these decisions for some delivery contexts and that more user-centered, use-initiative, AT-knowlege-based decisions must be enabled in the implementing protocols.
  28. reinvent Help and DoIt 
    where it says, in 10.1.8 Provide explanations, justifying the advice or information given
       If the user is expected to carry out a task or an action to achieve
       the desired level of security, they should have access to an
       explanation that justifies why it is necessary.
    Yes, yes, yes.
    Where the projection of the security infoset that the WG has nominated as "what to present" fails to communicate, and the user can recognize this, there needs to be built into the *easy* interactive fabric of Rich Web content a way for them to get more information when they will somehow manage to recognize that they care about the decision and don't grasp the info they need.  See comment to 10.1.7 for more.
  29. Know you don't know your users
    where it says, in 10.1.9 Understand the user
       Design should begin with an understanding of the intended users.
       This includes population profiles that reflect training, motivation,
       and goals
    please consider
     The situation here is just like Alcoholics Anonymous.  The first step is to admit that you don't understand the user.  So you have to create a dialog that collaborates, in a mixed-initiative way, with a diverse base of users with more diverse delivery contexts than you have time to learn about.
    Why? 
    The security underpinnings need to be part of the woodwork.  That is to say, universal.  You need Universal Design, not targeted design.
  30. User-adjustable step size is part of Universal Design 
    where it says, in 10.1.10 Create task profiles
       With the intended user in mind, designers should formally write down
       user tasks
    Yes, yes, articulate a task view.  However...
    Note that the step-by-step granularity in which tasks are accomplished is *not* universal.  Some delivery contexts mitigate in favor of smaller steps, some larger.
    please consider
    formalize these workflow models in UML/SCXML.  Stay in touch with the people in Multi-modal Interaction WG who are working on authoring in this medium for help in how to develop your specification-maintenance drill if you do so.
  31. consistency is good where it fits; it doesn't always fit; so undergird your consistency with a model 
    where it says, in 10.1.11 Consistency
     The cues should be displayed consistently in location and across
       sites and browsers in an attempt to prevent spoofing and user
       confusion.
    please consider

    Yes, you are going to publish good presentation practice.

    On the other hand, the deliverables need to create a semantic platform
    in terms of what the user should understand, and the evidence bearing on
    decisions that they have available to make.  Capturing this into a reliable
    model and encoding is essential for equal access for people with disabilities.
    Why? 
    There is no one presentation that works for all.  Discussed above/already.

  32. 'where' is less universal than 'how' for drill-down 
    where it says, in 10.2.2 The user must be aware of the task they are to perform
       The user must be aware that a decision is to be made, what
       information should be used to make the decision, and where to look
       for the information
    please consider
     s/where to look for/how to get
    Why? 
    Pagination, and hence even place-in-ToC varies with the delivery context.  If the user has to take the initiative to look for something, it should be a recallable item like '?' for 'Help' and not a ToC-path, a 'where.'  This is where object-oriented is the wrong model, and a globally-bound verb comes first.  Compare with the context menu in the GUI, not the man-pages department in the site map.  Infiltrating the Web 2.0 look and feel means re-inventing Help, not cruising with what is widely deployed.
  33. testing throughout evolution of product 
    where it says, in 10.3 Implementation and testing
       We will pursue resources that allow us to do
       more extensive usability testing, including:
         * Substantially different low fi testing for each iteration
         * Broader and more representative user population participating
         * Lab testing of sample code, for example [147]Johnny 2]
         * Contextual or "in the wild" testing of sample code [148]Social
           Phishing]
         * More iterative combinations of the above, throughout the
           specification lifecycle
    Hooray!
     This program is ambitious, but meritorious.  Wishing you all success.
    Please consider
    Investigate what can be done with high-function verification technologies such as NVDL and Schematron to aid authors (and user agents) in deriving information that bears on the conforming or non-conforming use of your suggested practices.  The flow here is from the logical model for security information to machinable checks targeted to two applications: things that get run on the author side in preparing materials for publication, and the same things get run on the client or a third-party service when it seems there's something not quite right in the State of Denmark.
    please consider
    Stay in touch with the Mobile Web Best Practices WG. They are ahead of you on the road in exploring new and better paths to testing and deployment.
    please consider
    Keep a journal.  The WAI stands fair to gain from anything you learn.

Recapitulation

Not so fast

This document reads unfortunately as if the Working Group believes that one reserved presentation of one summary level of the security situation will solve the problem of weak user awareness and understanding of the security aspect to the actions they take in web browsing and web commerce.  Unfortunately, this easy shortcut is an illusion; you have to follow the harder road.

The two major reasons why consistent presentation is not the silver bullet it might seem are a) the infrequency of security-problematic micro-contexts in web browsing, and b) the W3C commitment to serving people of diverse abilities and in diverse situations -- demonstrated by the existence of the Web Accessibility Initiative and Mobile Web Initiative.

The infrequency of malign security contexts will defeat any presentation convention.  Whatever we choose as the way to present the security placard for the current context, even if we do (unlikely as it is) persuade or force others to stay out of that particular presentation-styling niche, that will fade into the ignored background of the user's awareness.  As Cheryl Trepanier put it so well, "People are adapted."  This is where habit is our enemy.  If our styling is recognizable, and the information presented in that styling is routinely boring, the user will learn to ingnore, not attend to, whatever we send them by way of security coaching in that presentation.

Separation of presentation and content is a watch-word of accessibility, and enshrined in the Web Architecture.  But the establishment of a forearm's-length separation while stustaining effective presentation and interaction is an art.  You can succeed in this art, but it takes a) strategic recognition that a clear model is a goal and b) tactical methods that will let the model evolve out of what you would be doing anyway, rather than a radical reset and restart of the process.

But you know that

The seeds of a successful strategy are all here.  

The recognition in 10.1.8 and 10.2.2 that whatever summary indication is given in 'push' mode has to be backed by a more detailed situation explanation available to user 'pull' means that the pool of user-accessible information is deeper than the glint in the proposed presentation.  Amen.  Here's the conditional content the UAAG is talking about.  So the level at which the security situation is presented is subject to the user's initiative.  Our state chart for describing the (dialog-based) solution and performance measures that we are working on includes both the situation where the iconic status or event notification is present and the user chooses to question further or press on, and the state where they have chosen to ask for more explanation on the current security climate.  The path to success does not through summary go/no-go decisions made on the highest level of summarization, but in building habits of informed decision making, because the majority of situations are still benign.  The user should be double-checking more contexts than they abort.  The first transition (to ask for more) should be infrequent, and the second state (in which the user gets more) should be effective communication; not just the cues that condition that first transition.

The tacet recognition in 2.6 that new discipline in applying the established, endemic-in-the-wild security building blocks will be part of the solution.  We can't be responsible for the user's mistakes, but we can be responsible to the (initially small fraction of) users who exercise some skepticism.  To be responsible to the users whose attention we do get, we need sound information on which to base what we tell them.  That's where the encoding discipline of the ethical merchant community comes in.  If the benign merchant community doesn't exercise due hygiene to reliably populate the security information that our designed user-coaching works off, then the barn door is wide open for spoofers to do the same shoddy stuff as everyone and the user will get bad advice.

The commitment, exposed in 10.3, to an ongoing process of continual evaluation of what you are doing in the ground truth of user testing.  This shows that you are actually committed to results, not the the baseline ideas sketched here in framing your quest.

Backing into a Model


Didactic expositions of the Model/View or Model/View/Controller paradigm say "you start with a model."  This is not how it works in the real world.  To succeed in ending up with a model, work a spiral development with frequent re-factorization after the manner of Extreme Programming.   The ideal of the model is a concept lattice that links the concepts in the summary presentation through the concepts and complexes in the 'explanatory backup' level to the assertions that express precisely what each available security datum tells us.  Consider using SKOS to link the concepts that you are working with.  Even if the bottom layer of deployed security technology is  populated with keywords that are mnemonic in English, and the dominant mode of presentation of the highest level of summarization may be iconic, yet the middle layer of "how we explain to the user what it is that they should be aware of" should be localizable.  When dealing with tough nuts like explaining Web security at a non-trivial level, this is hard.  The concepts will have to be worked over to make them comprehensible by the layman.  Once you have done that work, a SKOS thesaurus of compare-and-contrast with more commonplace terms is in you heads; all you need to do is capture it.  Consider using assertion lattices after the manner of speech recognition as a model of what you know (dynamically, in the moment), from which you derive the user briefing.