W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Meeting record: WSC WG weekly 2007-04-04

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 12 Apr 2007 20:56:33 +0200
To: public-wsc-wg@w3.org
Message-ID: <20070412185633.GM2491@raktajino.does-not-exist.org>

The minutes from our meeting last week have been accepted yesterday.
They are available online:

A text version is included below the .signature.
Thomas Roessler, W3C  <tlr@w3.org>


                             WSC weekly 2007-04-04
                                  4 Apr 2007


   See also: [3]IRC log


          Thomas Roessler
          Rachna Dhamija
          Stuart Schechter
          Mike Beltzner
          Johnathan Nightingale
          Hal Lockhart
          Chuck Wade
          Jan Vidar Krey
          Luis Barriga
          Bill Doyle
          Tyler Close
          Rishikesh A Pande
          Phillip Hallam-Baker
          Dan Schutzer
          Mike McCormick

          Robert_Y, Yngve, Shawn, Tim_H, serge


          tlr, johnath


     * [4]Topics
         1. [5]approval of last minute's minutes
         2. [6]newly closed action items
         3. [7]robustness practices
         4. [8]TLS practices
         5. [9]What is a secure page
         6. [10]Workshop recommendations
         7. [11]Lightening Discussions of Proposed Recommendations
         8. [12]EV certificates
         9. [13]SSL/Certificate dialogs
        10. [14]wrap-up
        11. [15]TrustMe
        12. [16]wrap-up 2
     * [17]Summary of Action Items

approval of last meeting's minutes



newly closed action items

   no objections

robustness practices


   <Mez_> relevant URL - place in the wiki to record robustness things

   <Mez_> [20]http://www.w3.org/2006/WSC/wiki/RobustSecurityIndicators


   <johnath> tlr - I can try to scribe if you'd prefer

   <Paul> I don't have access to a phone again. Sorry.

   <beltzner> hal, are you scribing?

   tlr: summarizes e-mail and robustness...
   ... Jan Vidar, Beltzner, Johnathan, willing to reopen these?
   ... also, question to Staikos in here who isn't there today ...

   johnath: what kind of thing?

   tlr: borderless pop-ups and the like

   johnathan: sure

   <scribe> ACTION: nightingale to summarize robustness practices in terms of
   limitations on sites' freedom [recorded in

   <trackbot> Created ACTION-175 - Summarize robustness practices in terms of
   limitations on sites\' freedom [on Johnathan Nightingale - due 2007-04-11].

   tlr: jvkrey, same for you?

   jvkrey: sure

   <scribe>  ACTION: krey  to  summarize robustness practices in terms of
   limitations on sites' freedom

   <trackbot> Created ACTION-184 - summarize robustness practices in terms of
   limitations on sites\' freedom [on Jan Vidar Krey - due 2007-04-18].

   tlr: how much time?

   <scribe> ScribeNick: johnath

   <tlr> ACTION-175, ACTION-184 due in two weeks, tlr to change in tracker

   tlr: how much time is needed

   jvkrey: 2 weeks sounds good

   johnath: agree

   tlr: Mez_ do we have regrets for Staikos?

   Mez_: no, no regrets

   <tlr>  ACTION:  thomas  to ping george staikos by e-mail and negotiate
   corresponding action [recorded in

   <trackbot> Created ACTION-176 - Ping george staikos by e-mail and negotiate
   corresponding action [on Thomas Roessler - due 2007-04-11].

   <jvkrey> johnath: yes, he said so last week

TLS practices



   <tlr> [26]http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors


   tlr: we had actions around documenting user agent behaviour with SSL cert
   ... need to look into where there are matches/mismatches
   ... volunteers?

   beltzner: we have asked our security community about this kind of flow
   chart, but they don't have one


   beltzner: this is the wrong way to approach it - we should care more about
   the user-visible errors than the decision flowchart

   tlr: yngve sent a similar list for opera as beltzner did for mozilla. Agree
   we don't need full flow chart, but we do need to understand what the user is

   tlr:   someone  needs  to  look  across  the  browsers,  to  see  what
   consistencies/differences exist

   Chuck: what kind of problems are we solving here, where is our scope

   tlr: we want to understand what questions the major implementations expose
   to people wrt TLS/SSL validation problems

   <beltzner> "how are we dealing with the user interface issues?"

   Chuck: the variation between browsers is bigger than I expected.

   <beltzner> "poorly"

   Chuck:  different  tools  about  managing certs, different OS-specific
   dependencies, different rules about overrides

   <Mez_> can you turn "poorly" into an "antipattern" recommendation? I've
   tried that with one of the items I've put in the recommendations list, to
   see how it flies

   <beltzner> Mez_, that's a pretty good idea

   <beltzner> "don't do it this way"

   Chuck:  to  address this - we need experts assessing the landscape and
   providing common recs

   <Mez_> here's the antipattern one I put in

   <Mez_> [29]http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge

   tlr: We are taking the first step towards that, documenting in this group
   the behaviour of the browsers

   <Paul> In the MS case, the scenarios get quite complicated since browser
   behavior  is  also  dependent on host OS, and many, many configuration
   parameters that may or may not be in the user's control.

   tlr: I'd like to keep away from the deeper stuff for now, and focus on the
   first issue around the errors/warnings in browsers

   beltzner: things like validating ssl certs are out of scope - lower level

   <Mez_> yes Paul, I doubt we can do anything "completely", given that

   tlr: but the UI presented by the user agent as a result is in scope
   ...  so  do we have a taker to survey across the browsers and look for

   Mez_:  standards  bodies can include documenting existing common-sense

   <Chuck>  I guess we've discovered something that is both hard and time

   beltzner:  the  impediment  is  that  I  don't  want  to install every
   ... cross-referencing is more containable than cataloguing

   tlr: agree

   beltzner: then I will take the cross-referencing item

   <Paul> If there is a wiki page that demonstrates how we want to document the
   different behaviors I should be able to convince some co-workers to document
   at least some common scenarios in a similar format. However, it will be much
   easier to get that resource commitment if I can show them an example.

   <tlr> ACTION: beltzner to aggregate material on TLS user interaces across
   browsers, based on input from vendors - due 25 April 2007 [recorded in

   <trackbot> Created ACTION-177 - aggregate material on TLS user interaces
   across  browsers,  based on input from vendors [on Mike Beltzner - due

What is a secure page

   <Mez_> Paul there are some examples in the agenda on this item; any of them
   what you were hoping for?


   tlr: do we have any takers for the task of summarizing, as mentioned in the
   linked note?

   <Paul> OK, are agreed that we want screen snapshots of the dialog boxes and
   description of the scenario that led to the dialog box?

   <Mez_> Paul, yes, I like that format

   <Paul> I'll see if I can get the commitment from our SWRT group.

   <tlr> ACTION: yngve to pull together mixed content / "what is a secure page"
   material from earlier list discussions - due 18 April 2007 [recorded in

   <trackbot> Created ACTION-178 - pull together mixed content / \"what is a
   secure page\" material from earlier list discussions [on Yngve Pettersen -
   due 2007-04-18].

   tlr: lacking any volunteers, I will give it to Yngve, who had offered by
   e-mail to take it

Workshop recommendations

   <tlr> [33]http://www.w3.org/2006/WSC/wiki/InScopebyCategory

   tlr: I'd like to ask hal if he can look at extracting concrete recos from
   the wiki page in terms of sizing

   hal: honest answer is, I haven't thought about it. I had been assuming the
   doc would be more of a checkklist for proposals generated elsewhere...
   ... but I see your point. There is value here, but I don't have a sense of
   how much work it would be. A day or two, maybe, at most.

   tlr: Suggest that we log an agenda item for the f2f in late May to revisit
   this list

   <tlr>  ACTION:  zurko  to put check of recommendation material against
   InScopbyCategory  wiki item on f2f agenda; find volunteer to lead that
   discussion - due 15 May 2007 [recorded in

   <trackbot> Created ACTION-179 - put check of recommendation material against
   InScopbyCategory  wiki item on f2f agenda; find volunteer to lead that
   discussion [on Mary Ellen Zurko - due 2007-05-15].

   maritzaj: are we recommending what not to do, as well?

   Mez_: thomas - would you give maritzaj an action to map existing usability
   research to status quo in terms of best/worst practices

   <tlr> PROPOSED ACTION: maritza to make pass to SharedBookmarks and other
   material; map testing results to status quo

   <tlr>  ACTION:  maritza to make pass through SharedBookmarks and other
   material;   map   testing   results   to   status   quo  [recorded  in

   <trackbot> Created ACTION-180 - Make pass through SharedBookmarks and other
   material;  map testing results to status quo [on Maritza Johnson - due

   <tlr> ACTION-180 due on 2007-04-18

   Mez_: these can be turned into anti-pattern recos as well

Lightening Discussions of Proposed Recommendations

   <tlr> ScribeNick: tlr

   <Mez_> [36]http://www.w3.org/2006/WSC/wiki/RecommendationIndex

   MEZ:  list  of possible recommendations; thanks to everybody who added
   ... on different levels of detail ...
   ... one of the talk of doing lightning discussions is to get feed-back ...
   ... idea is to talk about an item for 5 min, then trash^Wdiscuss it for
   10min, then move on ...
   ... let's try that structure ...
   ... MEZ to monitor the time ...
   ... will take fairly literally ...

   <ses> <--dropping off shortly.

EV certificates

   MEZ: Phil, want to lead discussion on that, introduce the topic and possible

   phb: I was muted
   ... the basic idea of EV certs is accountability ...
   ... when somebody shops online ...
   ... they should know when their transaction is governed by accountability
   ... and when it isn't ...
   ... if I go online and buy expensive hi-fi from unknown ...
   ... and buy it from a shop that's not accountable, I might have lost my
   $3000 ...
   ... no redress ...
   ... money handed away, no effective redress...
   ... but if I know the shop well, know there will be accountability ...
   ... then I can buy with confidence ...

   <ses> signing off

   phb: idea is if I go to the shop and I know they are a registered business
   ... that gives degree of confidence ...
   ... that civil process can be served ...
   ... not about absolutely preventing something bad going wrong ...
   ... can buy plasma tv, company might be crook ...
   ... but know there's recourse ...
   ... deal with party that can be held accountable ...
   ... through law ...
   ... that makes big difference to security ...
   ... idea is to have set of standards that are minimum across CA industry ...
   ... CABforum ...
   ... it includes the major CAs ...
   ... and most of the browsers ...
   ...  the  thing  about  accountability  is  that  it's  not just about
   accountability for cert holder ...
   ... but also for issuing CA ...
   ... important element of IE7 EV user interaction ...
   ... people also get to see who issued cert ...
   ... that's critical ...
   ... if CA screws up ...
   ... and there will be failures ...
   ... failure rate is << 1% ...
   ... but there are bad certs ..
   ... make sure the issuer name appears in the chrome ...
   ... so when the Times complains, the trademark and confidence get tarnished
   ... all about accountability ...
   ... consumers either have accountability to actual merchant ...
   ... or to issuer of cert ...
   ... in future years, new classes of certificates may be ...
   ... insurances and other things like that built into certificates ...
   ... also, IE7 UI changes for EV certs ...
   ... any bowser can do that ...
   ... you see the subject name of the cert in the right hand side ...
   ... name of the company that the CA has vetted, rather than just domian nae
   ... domain names are easy to come by ...

   mez: which parts of EV are appropriate for REC?
   ... about how to represent quality and signer? ...

   phb: representing the quality is important ...
   ... distinguishing between EV and non-EV is important ...
   ... that is what browser vendors and CAs went into process to achieve ...
   ... displaying issuer is really crux of it ...
   ... if you don't, you don't get accountability ...

   johnath: would like to supplement answer ...
   ... company name is important, rather than just domain name ...
   ... these are concrete pieces of information to extract from EV ...
   ... support different treatment ...
   ...  do  want  to get to whether we are also contemplating specific UI
   recommendations ...

   phb:  need  to  make  sure that folk don't confuse the issue by having
   presentations that suggest green bar for things that aren't EV cert
   ... think it would be appropriate to come out with some kind of statement

   <johnath> [37]http://blog.johnath.com/images/Identity%20Verified.png

   phb:  other  possible  approach would be to allow user to customize EV
   experience themselves ...

   <johnath> mockup of another EV presentation style

   phb: pros and cons to that approach ...
   ... some help against picture in picture, but some also mean each user has a
   different experience ...

   chuck: want to poke at some of the assertions regarding how user should
   interpret indication that they deal with EV authenticated site ...
   ... implication was that somehow user is safer, might have recourse ...
   ... that seems to be slippery slope ...
   ... have never heard of CA backing up claim against malfeasance of biz ...
   ... is that practical to imply?

   phb: CA at this point isn't insuring transaction.
   ... technically possible if the business model is right ...
   ... but might have defined process ...
   ... process in place that makes it likely that regress can be found

   chuck: another benefit is enforcement of OCSP
   ... yet to see a browser that reports the success of OCSP check ...

   phb: don't believe that current draft requires OCSP
   ... sth that VSGN argued for, but would have to re-read ..
   ... current req might be "must be revocation supported"

   <johnath>   thinking   on   alternate  EV  UI  (per  Mez_'s  request):

   <Zakim> tlr, you wanted to ask what "different" would be and to also comment
   on the green bar

   <Paul> I'm concerned that EV certs become worthless if the storage of the
   root certificates on the user's machine become compromised. This leads me to
   think  that  we  would also need to make recommendations regarding how
   certificate stores are managed and updated.

   <Zakim> johnath, you wanted to reply to chuck's interpretation of EV=safety

   <Zakim>  paul,  you  wanted  to ask Does lead us to also make specific
   recommendations about how root CAs are managed for all platforms?

   <scribe> ACTION: hallam-baker to summarize EV cert discussion and deliver
   proto  recommendations  in  Wiki  -  due  18  April  2007 [recorded in

   <trackbot> Created ACTION-181 - summarize EV cert discussion and deliver
   proto recommendations in Wiki [on Phillip Hallam-Baker - due 2007-04-18].

SSL/Certificate dialogs

   e.g. [40]http://lists.w3.org/Archives/Public/public-wsc-wg/2006Dec/0166.html

   mez: michael, do you have recommendations here?

   mikeMcC: bad example from MS ...
   ... there's an anti-pattern in here ..
   ... would be happy to turn that into an anti-pattern ..

   mez: 5 min!

   mike mcC: visited web site -- think it's X9 ...

   scribe: they didn't chain to root ...
   ... was led by IE6 UI down a rabbit hole of incomprehensible error messages
   ... interesting terminology ...
   ... request to contact the very URI I was trying to visit, but which led to
   the problem ...
   ... slightly crazy ...
   ... core anti-patterns use of obscure technical jargon ...
   ... even if user knows what certificate is ...
   ... use of punting to web site as anti-pattern ...

   tlr: the mozilla dialogue...
   ... action advice to users should be safe and feasible ...
   ... trustworthy and untrustworthy information must be marked clearly; don't
   lead users to decide based on untrustworthy information ...

   mikeM: +1; not easy to distinguish to distinguish a chrome-like dialogue
   from one that might have come from javascript ...

   <beltzner> +q

   <tlr> the one I'm talking about is here:

   mikeM: think these are good anti-patterns in addition to jargon ...

   chuck: there's the certificate for the site ...
   ... and there's context information ...
   ... what's confused is the context information for issuers ...
   ... there are some problems with CAs that aren't known by browser ...
   ... context you're really dealing with not the cert you visit, not the root,
   but an intermediate ...
   ... there's almost no guidance to what the significance is ...
   ... browsers and other UIs take user into context that's separate from site
   ... take then into context to deal with issuer, give them tools to deal with
   the issuer ...
   ... current practice is source of a lot of confusion ...

   <tlr> see [42]http://www.w3.org/2007/03/30-tlr-budapest.pdf, slide 64, btw

   beltzner: if user ever gets to that dialogue, then they've lost
   ... it's all gobbledygook ...
   ... the real anti-pattern is we shouldn't be asking users questions that
   they can't reasonably answer ...
   ... these are asking users questions that they can't reasonably answer ...
   ... if somebody has a properly validated cert, then users shouldn't see this
   ... can find a lot of metaphors ...
   ... the anti-pattern is exposing the technology model ...

   phb: hang on, two questions here ...
   ... "why is this not paypal" ...
   ... "why isn't this somebody I expect" ...

   <Chuck>  I  agree,  it's  gobbledygook  to me as well, and I've set up
   multi-level cert hierarchies. My point is that the dialogues are dealing
   with something that is outside of the user's context. Either take them into
   a context where they can deal with the problem, or give them a rational
   interpretation of how to proceed, or not.

   phb: keep slipping into idea that problem knowing "is it" paypal ...

   <Mez_> PKI and bookmarks and petnames and such; all ways to say "is this
   someone I should have heard of"

   phb: or "is Victoria British" ...

   tlr: what's the positive recommendation here.

   beltzner: suggesting that exposing the technology is an anti-pattern ...
   ... will make suggestions as part of dealing with prior action ...

   johnathan: coming back to tech layer and validating intermediary CAs isn't
   going to give answer about the trusted vendor

   phb: Generically, if we get into that dialogue, 99% of the cases we are at
   the Victoria British site ...
   ... and some bozo hasn't renewed cert ...
   ... these dialogues were in there as a debugging tool ...
   ... I've been told ...
   ... agree that it isn't useful ...

   <johnath> Mez_: duly noted

   <johnath> :)

   phb: conclusion we're drawing here is "this ain't victoria british" ...
   ... it might mean they've just done some sort of boo-boo ...

   mikemc: some more detail about the example that started this ...
   ... it was x9.org ...
   ... I was on that site ...

   <PHB> Maybe the recomendation here should be for Web SERVERS, do not present
   a stale cert

   mikemc: never really in doubt ...
   ... they used their own CA ...
   ... that root wasn't in the key store ...
   ... [reads the IE message] ...

   <Chuck> The reality is that lots of users are getting errors relating to
   intermediate CAs, so we have a larger problem that the security context is
   "too  complex" for real users, and even security experts. This kind of
   problem crops up even when the site's cert is valid, but the chain is not
   recognized by the user's browser.

   mikemcC: what are the consequences of clicking "yes"? What are the risks?

   mez: take notes, put together updated item into wiki with possible recs

   <PHB> My take on the X9 situation: turn on SSL without bothering the user at
   all. Just don't show the padlock or anything that says secure

   <PHB> Incidentaly, this issue does not occur with EV, it is not possible to
   add an EV root to the store as a user.

   <scribe> ACTION: McCormick to summarize TLS discussion and extract proto
   recs into wiki [recorded in

   <trackbot> Created ACTION-182 - Summarize TLS discussion and extract proto
   recs into wiki [on Michael McCormick - due 2007-04-11].

   <scribe> due at same time as Beltzner's action to summarize prior input
   about TLS


   MEZ: we're running out of time

   Tyler: I'd have a good use for 4 min of presenting


   Tyler: segways nicely from the certificate discussion ...
   ... browser shouldn't ask unreasonable questions ...
   ... URI inside domain name includes arbitrary delegation chain ...

   <Mez__> [44]http://www.w3.org/2006/WSC/wiki/TrustMe

   Tyler: users odn't understand that ..
   ... similar to cert chain, there's long sequence of updated RFCs ...

   Tyler: to define the semantics, that took a while ...
   ... asking users to vet URIs is unreasonable ...
   ... users can't do it ...
   ... recommend against displaying URI on top of the page ...

   beltzner: have you seen any of the location bar ^2 discussion?
   ... demoed this at last f2f ...
   ... gone through cycle from reasonable through crazy through reasonabe ...
   ... doesn't show full URI ...
   ... strips some useless stuff off ...

   tyler: update available?

   <johnath> wiki discussion of locbar2:

   beltzner: johnathan is working the laptop
   ... it dovetails nicely into some sort of interface recommendation ...

   <johnath> project page for locbar2

   tlr: I think there's a flip side in here that users need *some* way to get
   to the URI

   johnathan: location bar ^2 goes back to original URI on hover ...
   ... can edit as a text box ...
   ... stylized when not interacting, to remove the useless parts ...

   beltzner: maintain type-in ability, but take away distraction
   ... more understandable display ...

   tyler: dispute the notion that expert users can safely use URIs
   ... if you have a name that's a close homograph ...

   beltzner: don't disagree ...
   ... only saying that modifying URI is an interaction that's still available

   tyler: requirement that there be a way to type in a URI?

   beltzner: type in and modify?

   tyler: mode where you hit key and then you've got a dialogue -- is tha tok?
   ... but no version displayed on default screen?
   ... would that take care of requirements?

   beltzner: close, but there are ways to do this without modal interfaces

   tyler:  confident  that there is display of domain names that prevents
   homograph attacks?

   beltzner: we're getting closer

   tlr: a rec would speak about this in the abstract, then list implementation

   <scribe>  ACTION: tyler to go over TrustMe notes, update in wiki - due
   2007-04-18 [recorded in

   <trackbot> Created ACTION-183 - go over TrustMe notes, update in wiki [on
   Tyler Close - due 2007-04-18].

wrap-up 2


   mez: next week
   ... we'll continue ...
   ...  please request other agenda items if there are things you want to
   discuss ...
   ... please do what you can to get them in ...
   ... meeting adjourned ...

    Minutes formatted by David Booth's [48]scribe.perl version 1.128 ([49]CVS
    $Date: 2007/04/12 18:50:51 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0012.html
   3. http://www.w3.org/2007/04/04-wsc-irc
   4. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#agenda
   5. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#approval
   6. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item01
   7. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item02
   8. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item03
   9. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item04
  10. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item05
  11. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item06
  12. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item07
  13. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item08
  14. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item09
  15. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item10
  16. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#item11
  17. file://localhost/home/roessler/W3C/WWW/2007/04/04-wsc-minutes.html#ActionSummary
  18. http://www.w3.org/2007/03/28-wsc-minutes
  19. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0009.html
  20. http://www.w3.org/2006/WSC/wiki/RobustSecurityIndicators
  21. http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice
  22. http://www.w3.org/2007/04/04-wsc-minutes.html#action01
  23. http://www.w3.org/2007/04/04-wsc-minutes.html#action02
  24. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0008.html
  25. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Feb/0050.html
  26. http://www.w3.org/2006/WSC/wiki/NoteKDECertificateValidationErrors
  27. http://www.w3.org/2006/WSC/wiki/%20NoteMozillaCertificateValidationErrors
  28. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Feb/0050.html
  29. http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge
  30. http://www.w3.org/2007/04/04-wsc-minutes.html#action03
  31. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0007.html
  32. http://www.w3.org/2007/04/04-wsc-minutes.html#action04
  33. http://www.w3.org/2006/WSC/wiki/InScopebyCategory
  34. http://www.w3.org/2007/04/04-wsc-minutes.html#action05
  35. http://www.w3.org/2007/04/04-wsc-minutes.html#action06
  36. http://www.w3.org/2006/WSC/wiki/RecommendationIndex
  37. http://blog.johnath.com/images/Identity%20Verified.png
  38. http://blog.johnath.com/index.php/2007/03/21/revisiting-security-ui-part-2/
  39. http://www.w3.org/2007/04/04-wsc-minutes.html#action07
  40. http://lists.w3.org/Archives/Public/public-wsc-wg/2006Dec/0166.html
  41. http://www.w3.org/2006/WSC/wiki/NoteMozillaCertificateValidationErrors?action=AttachFile&do=get&target=mozillaSSLerror-generic-warning.png
  42. http://www.w3.org/2007/03/30-tlr-budapest.pdf
  43. http://www.w3.org/2007/04/04-wsc-minutes.html#action08
  44. http://www.w3.org/2006/WSC/wiki/TrustMe
  45. http://wiki.mozilla.org/Firefox3/Location_Bar
  46. http://en.design-noir.de/mozilla/locationbar2/
  47. http://www.w3.org/2007/04/04-wsc-minutes.html#action09
  48. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  49. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 12 April 2007 18:56:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:44 UTC