See also: IRC log
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0356.html
<staikos> I can't complain
Mez: any complaints?
... minutes approved
Mez: did not hear any issues on list
... items closed and approved
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0256.html
Michael: assuming we're familiar with
favicons
... icons that appear in title bars, etc
... some concerns about favicons on security context
... users are beginning to view favicons as part of security context
... compounded by the fact that it appears in chrome
... any entity can steal or create their own favicons
... no central authority for favicons
... favicons should be treated as a security anti-pattern
... undermine security context display
... blur the distinction between chrome and content
... some things that could be done to make them more secure
... tied to dns? crypto?
... ensuring no two sites use the same one, etc
<staikos> Michael is describing logotype
Mez: checking for concerns
yngve: example... the major banking
clearinghouse in norway
... has a favicon from netscape
staikos: favicons have been a concern at kde
... what to do with invalid certs
... dont want a popup dialog just for favicons
... perfect ssl or ignore favicon
... useers would confuse konqueror icon and favicon
... users not knowing what favicons are
... hard to use favicons as logos because of size/resolution
... the secure version would be a logotype extension
... philip could speak to this
Tyler: michael's description... should
recommend that browsers not display favicon
... without vetting
... is this possible from the browser dev standpoint?
<staikos> I predict user revolt
yngve: needs to check with usability people
... thinks users would miss them
... websites might also want them
<staikos> I agree with yngve
<Audian> require EV cert?
Tyler: if we cant remove favicons, can we add
some vetting or conditions?
... is that acceptable to users/websites
<staikos> KDE doesn't display it if it comes via SSL and the cert is expired/invalid/self signed/etc
staikos: if we require cert, we should jst require logotype extension
tyler: example on restrictions
... ???
missed that one
<staikos> that sounds like a browser extension to me - not something to build in
<jvkrey> only display it when the site is infact in favourites/bookmarks ?
<Audian> me too
<serge> I agree
serge: back on ev cert issue
<Mez_> tyler: how about only showing favicon if the user has configured some sort of trust, like a petname?
serge: seems silly to display only when there
is a EV cert
... still relying on arbitrary third party
Mez: thoughts on tyler's suggestions?
serge: good idea, but may be out of scope
Mez: petnames and favicons are not out of
scoper
... any more on favicons?
... similar concerns as george regarding favicon and url display
... is there anything about favicons and how they interact.. ie, research
rachna: looked at favicons
Mez: are they useful or confusing?
rachna: users love them and rely on them as an
important indicator
... maybe more than https
... maybe more than url
... they are misunderstood
yngve: any difference between tab icon and url
mez: any more on favicons?
... Michael can you update favicons in wiki?
... personally would support favicons recommendations
<scribe> ACTION: Michael to update favicons in Wiki [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action01]
<trackbot> Sorry, amibiguous username (more than one match) - Michael
<trackbot> Try using a different identifier, such as family name or username (eg. mmccormi, msmith9)
<staikos> I find it hard to imagine removing favicons anytime soon
<scribe> ACTION: Mike_McCormick to update favicon in wiki [ - due 2007-05-16 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action02]
<trackbot> Sorry, couldn't find user - Mike_McCormick
<PHB> I think that the recommendation on favicons should emphasize the unauthenticated nature of the information presented and the abmigous security situation
<staikos> my corporate firewall could b e adjusted to block it too
<jvkrey> :)
<scribe> ACTION: McCormick to update favicons in wiki [ - due 2007-05-16 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action03]
<trackbot> Created ACTION-208 - update favicons in wiki [ [on Michael McCormick - due 2007-05-02].
<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0285.html-
<staikos> PHB: logotype seems like the right choice for the future on secure pages. On insecure pages users want a way to create bookmarks with meaningful icons, and to find the right tab in their browser
yngve: limit the definition of secure page
<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0285.html
<staikos> hm that should have been PHB,
yngve: can't assess security of client
... padlock is indicator of client's evaluation of security
... opera uses every element including redirects
... opera includes key strength, warnings, ocsp info
... other client may use different criteria
... primary problem: how to handle mixed security elements
... and redirects
... form submit between secure/insecure
... padlocks on insecure pages
... suggestion - how to recommend the behavior of services
... e.g. no padlock, discourage unsafe practices
Mez: struggling with issues raised
... may begin to include ajax/json
... what to do with mixed content
... we havent dealt with it in proposals yet
... anyone have ideas regarding mixed content?
yngve: secure main page with insecure images
... having it secure will cost too much
Bill: mixed security for user content or
ads?
... user data in mixed content ties in with previous thread
... what do you mean by mixed?
Mez: reminded on action
... "everything"
... can we partition it?
Bill: some doesn't matter... some users might care about
yngve: arbitrarily deciding whats important...
client has to tell
... either everything or mixed should be insecure
Bill: Can we differentiate between user content and other
yngve: has seen secure sourcing external insecure js
Bill: a payment page would likely be
"important"
... tough question
Mez: would like it to be part of the
recommendations
... any more comments on secure page?
<scribe> ACTION: yngve to update wiki with recommendation on mixed content [ - due 2007-05-16 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action04]
<trackbot> Created ACTION-209 - update wiki with recommendation on mixed content [ [on Yngve Pettersen - due 2007-05-02].
<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0289.html
McCormick: we spoke about an example of a site
with a self-signed sert
... confusing warnings and dialog
... promoting specific anti-patterns
... the 4 anti-patterns:
... use of technical jargon users may not know
... giving the site url as the only contact info
... suggesting actions that cannot be performed
... not explaining consequence of options
... Mez had some good comments... linked email to recommendation
... can we use that to launch discussion
Mez: first pattern... in this context and
johnathan's proposal...
... technical info is usually related to crypto pki
<staikos> PKI is not only hard in the browser
<staikos> it's hard everywhere
<staikos> that's why we have unencrypted email everywhere
Mez: dont know if anyone is aware of research
that can make crypto and pki understandable
... mapping them to errors
... any references?
<Tyler> petname tool
staikos: example..
<Mez_> what about petname takes on crypto/pki and makes it easier tyler?
staikos: sent email to tech support... attached
digital sig
... got encrypted response
... some software will do this automatically
... automation and transparency is key to implementation
Mez: familiar with some of this software
... dont know how they deal with errors
Tyler: details of crypto not important... the
guarantee is important
... a proper TLS session ensures some.. how to match that to user
expectiations
... petname tool only lights up when connection is secure to trusted party
Mez: How do we deal with errors, though?
... are errors discounted?
<Audian> Is the question about how 'we' deal with errors or how 'users' deal with errors?
Tyler: let's not try to define those errors to
user
... just tell them they cant trust... not why they cant
yngve: problem with errors...
... client expects user to continue but cant guarantee security
... if there is an error, dont display anything
Tyler: two scenarios
... either an attack is in process
... site is misconfigured
yngve: misconfiguration is most likely
... self-signed certs are an example
... attack scenario less likely
... what should the client do?
... does it not display error asking user to continue?
tyler: self-signed cert not a misconfiguration
yngve: its a misconfig from a client POV
<staikos> sometimes a self-signed cert IS a misconfiguration
<staikos> like "oops, forgot to install the cert I bought"
tyler: do self-signed certs represent the majority of "misconfigurations"?
yngve: webmail often has these problems
<staikos> I agree with Ingve.
yngve: cert often has wrong name
<staikos> I have been trying to encourage some of these webmail solution to repair their problems
tyler: domain name mismatches are a large portion
Mez: this is in our charter and goals... to
talk about configuration
... we need to identify context problems that arise from server
copnfiguration
yngve: high-trust sites should not provoke security errors.. .such as banks
Mez: any more comments on pki/crypto and errors in context info?
<scribe> ACTION: McCormick to encapsulate error and anti-pattern info to wiki [ - due 2007-05-16 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action05]
<trackbot> Created ACTION-210 - encapsulate error and anti-pattern info to wiki [ [on Michael McCormick - due 2007-05-02].
<Mez_> http://www.w3.org/2006/WSC/wiki/NoteKDECurrentPractice
staikos: kde tries to be robust but gets stuck
on compatibility issues
... any area people would like to hear about?
... haven't worked on all areas... been developed over a long time
Mez: some of our robustness recommendations
... do not allow content to make display area small
... move it off-screen, etc
... all could be parts of recommendation
staikos: agreed... but may be obsolete
... most browsers may already do this
Mez: agreed.. but may be worth including anyway
staikos: good to document... not entirely
obvious
... html spec does not forbid the things that we want to forbid
... we have one thread that runs js code
... errors would cause infinite loops
... now guards against long-running processes
Mez: is this a part of security indicators?
staikos: this was more of a stability to
issue
... to prevent unnecessary denial of service
Mez: smart pop-up blocker...
staikos: may not be a security issue
... must be careful not to become incompatible with other browsers
Mez: asked about stricter policies
staikos: those were related to networking...
... frames and ssl
... various browsers had different ways of relaying information to users
... initially, had very strict policies... had to relax them for
incompatibility issues
Mez: any comments on kde robustness
practices?
... no comments
<scribe> ACTION: staikos to add robustness info to wiki that may turn into recommendation [ - due 2007-05-30 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action06]
<trackbot> Created ACTION-211 - add robustness info to wiki that may turn into recommendation [ [on George Staikos - due 2007-05-02].
we may need to adjust due dates... they appear to not be recorded properly
Mez: is this something to be referred to another WG?
staikos: possibly
I'd like to defer to tyler since he's been working on most of it recently and I will chat with him offline
Tyler: thoughts laid out in email
<Mez_> can someone put in the url of tyler's email? I'll go looking...
Tyler: still more detail needed from people who
brought up the lightning topics
... need a champion for each recommendation
<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0349.html
Tyler: and to help design the test
... will people who bring up topics be the champion for those topics?
... create a template for what the proposal should look like
... section on what usecases it addresses
... need more input on the template from everyone else
Mez: would like to hear from people who
contribute to lightning discussions
... willing to do so for my lightning topics
DanSchutzer: willing to do so as well
Mez: mike, yngve... does this work?
McCormick: will a template be provided?
Mez: you can do it in two stages
... tyler can speak to when a template will be available
tyler: written up a usual...
... we develop a template together
... I could do it or we solicit feedback first
DanSchutzer: I'd be willing to do it..
... can we have a straw-man template
<scribe> ACTION: Tyler to create straw-man template for recommendations [ - due 2007-05-11 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action07]
<trackbot> Created ACTION-212 - create straw-man template for recommendations [ [on Tyler Close - due 2007-05-02].
Mez: earlier would be better if possible
Tyler: can I get feedback on other proposals outlined in email?
Mez: do we have an easy list to refer to?
Tyler: they're all listed in the note
Mez: 10.1 and 10.2
<Mez_> http://www.w3.org/2006/WSC/drafts/note/#usability-principles
Tyler: yes... list of usability principles... should be based on this
Mez: I like the idea... anyone else?
Tyler: section that lists security
information
... having a section of each recommendation referring to this would be
helpful
Mez: need a regular way for referring to these
Tyler: anyone else have suggestions on sections for the recommendation?
Mez: looking at the note... wondering if robustness proposals will have a different set
Tyler: most of those would reference usability principles
Mez: a good first pass for template
... can imagine other references...
... presentation
... not sure they should be part of the template
Tyler: each section should list goals of the
group it meets
... 4 hypothetical section for the template
... what do you need to read for recommendation?
*crickets chirping*
<tjh> thanks
Mez: you covered much of it...
... what kind of testing we do on each of these
... how do we get from a cluster of proposals to implementation and
testing
... anyone have ideas on how they will be involved?
... think about how you might be involved and how we make that transition
... will bring it up in email
Tyler: at the last f2f, staikos talked about a
scriptable browser implementaiton
... for testing
<rachna> We should start with lo-fidelity testing to determine the set of proposals that can be implemented in hi fidelity prototypes and tested formally.
<staikos> (following along... sorry but it's just not ready enough yet - I got side tracked with work and couldn't finish the last 5%)
tyler: what do you need in a proposal?
... for lo fidelity testing
rachna: can be done at any stage of the prototype...
<Mez_> staikos, what will you need from a proposal to figure out if it can be implemented in the prototyping framework you're proposing use of?
rachna: need to specify the feature
... person who proposes it may need to propose how to test it
<staikos> just a detailed list of features. basically there is -nothing- there
rachna: specify how or what to test each
proposal
... need to be specific to make the prototype easier
... prototyping is a way to do design
... getting feedback on implementation
maritza: may need to have alternatives for testing
racha: may need to different variations on each proposal
Tyler: does your testing line up with our lightning discussions
rachna: some does.. tyring to differentiate whats in-scope and whats not
Tyler: are logotypes in scope
Mez: hasn't made a statement regarding them
... will try to identify when something is out of scope
Tyler: there is already a published rfc on
logotypes
... sounds like they are fully-specified
... what sort of role do you (rachna) envision playing in the proposals?
... or focus more on testing?
rachna: can make proposals and can do testing
Tyler: any lightning proposals that you would like to write up for dublin?
rachna: yes
<serge> I need to get to another meeting.
<Mez_> so shawn, it's to put a lightening proposal in the wiki based on her current work
<Mez_> as the action
<Mez_> by may 11
<scribe> ACTION: rachna to write a lightning proposal in the wiki based on her work [ - due 2007-05-11 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action08]
<trackbot> Sorry, amibiguous username (more than one match) - rachna
<trackbot> Try using a different identifier, such as family name or username (eg. rdhamija2, rdhamija)
<scribe> ACTION: rdhamija2 to write a lightning proposal in the wiki based on her work [ - due 2007-05-11 ] [recorded in http://www.w3.org/2007/05/02-wsc-minutes.html#action09]
<trackbot> Created ACTION-213 - write a lightning proposal in the wiki based on her work [ [on Rachna Dhamija - due 2007-05-02].
Mez: next week we're off
... will send a reminder
... thomas will be chairing next meeting on 16th