See also: IRC log
<trackbot> Date: 09 July 2008
<Mez> Agenda: http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jul/0004.html
<Mez> tlr, there's no june update on the scribe list at all
<Mez> http://www.w3.org/2006/WSC/scribes
<scribe> ScribeNick: johnath
Mez: okay, we have an agenda, chair, and scribe
<Mez> http://www.w3.org/2008/07/02-wsc-minutes.html
Mez: I haven't heard any
objections
... our charter has been extended to June 2009 - sent an email
today
RESOLUTION: minutes approved
<Mez> http://www.w3.org/2006/WSC/track/actions/open
Mez: don't have a lot that are
pressing
... no issues on this topic
Mez: the agenda has just one
topic - next steps on web authoring best practices
... we spun this document out in Oslo as a separate document,
in part because we weren't clear on the intended level of
stricture required
... next meeting, want to get going more concretely on
application testing
... anyone have any other agendums?
<Mez> http://lists.w3.org/Archives/Member/w3c-ac-members/2008JulSep/0002.html
Mez: will link to official
Charter renewal email
... I presume that the content of the email serves as informal
notification of the expectations for the workgroup during the
extension
... includes LC for wsc-ui and moving forward with a rec-track
document about authoring guidelines
<Mez> http://www.w3.org/2006/WSC/drafts/wsc-content/
Mez: as anil pointed out earlier
in IRC, the current document is basically just an extraction of
the relevant portions of the old wsc-xit
... anything not in section 2 is basically boilerplate
... obviously one of the things we should talk about is where
we go with this, how to review what's there, but I also wanted
to open this up to general discussion and brainstorming about
content, philosophical vision for the document
... I have thoughts that I will send out by email
ifette: My only concern that we
had back in Oslo is that it seems to go against what a lot of
big sites are doing
... I'm worried about putting out a best practices document
that major sites don't follow
Mez: right, that's the big question - do we conform to current implementation expectations, or do we set a high bar with an attempt to pull them in a given direction
<Mez> johnath: likes the idea of the doc, good point ian.
<Mez> ... generically, what it should include, are there any similiar attempts? magazine articles exist.
<Mez> ... unlike UI guidelines piece where doc doesn't exist, a doc like ths must exist, there must be man
<Mez> ... where might we find some?
Mez: does anyone on the line work on deployed websites, able to offer guidance
<scribe> ACTION: johnath to scour web and attempt to synthesize out "commonly recommended practices" for web authors [recorded in http://www.w3.org/2008/07/09-wsc-minutes.html#action01]
<trackbot> Created ACTION-490 - Scour web and attempt to synthesize out \"commonly recommended practices\" for web authors [on Johnathan Nightingale - due 2008-07-16].
<scribe> ACTION: mez to poll group members for site authoring expertise [recorded in http://www.w3.org/2008/07/09-wsc-minutes.html#action02]
<trackbot> Created ACTION-491 - Poll group members for site authoring expertise [on Mary Ellen Zurko - due 2008-07-16].
tyler: a couple years ago,
Hertzberg (sp?) surveyed a number of sites using non-ssl login
pages
... more recently, Jackson's force-https tool
Mez: can you elaborate that?
tyler: force-https - it's a tool
that forces http links in src to rewrite as https, or throw up
a red flag whenever you were including unsecured content
... I think both of those address the kind of issues we're
talking about - how ambitious should we be? It speaks to the
ability to move, even large websites
yngve: I was going to say
something similar to what tyler said. You don't get movement
until you draw attention to it. Name and shame - point out bad
practice.
... there might be something to be said for actually saying
"this is bad, and we shouldn't do it"
... I'm starting to wonder whether us browsers should start
doing something there, but it's sort of a chicken and egg
problem with breaking sites
Mez: since you mention that - do you believe that all the things websites should do are already in the draft of the document we have?
yngve: I think we at least suggest that websites should not mix secure and unsecure content
http://www.w3.org/2006/WSC/drafts/wsc-content/
scribe: not putting login on an
unsecured page that submits to a secure one
... there are borderline cases, like google's mail which goes
unsecure after login
johnath: do you want an action to review the document and add in anything you think we've missed
yngve: I think they're there, but I haven't reviewed the document recently
Mez: it seems to me that FSTC might have some guidance to give to websites, we should see that it is appropriately reflected in the document
yngve: I think we got most of it
<Mez> http://www.w3.org/2006/WSC/drafts/wsc-content/#tls-consistency
yngve: there might be some change
to make in a subpoint to make it clearer
... perhaps it's worth having explanations about why each
practice is good/bad
Mez: either there, or in security considerations
yngve: given that this is intended for the authors of web sites, I think reasoning should be pretty close to the recommendations
Mez: if anyone can think about
people that might be good resources - individuals or
organizations (particularly w3c members) then I'm certainly
willing to reach out to them
... are there web sites out there that are points of focus?
tyler: people have been singing the praises of paypal lately
Mez: are they members of w3c?
<Mez> http://www.w3.org/Consortium/Member/List
PHB2: I thought so, but maybe not
Mez: not on the list
yngve: microsoft might have some expertise on sites breaking due to mixed security content
Mez: you have ebay contacts, phil?
PHB2: yep, we have contacts there - give me an action item
<scribe> ACTION: PHB to Contact ebay about paypal web authoring best practices [recorded in http://www.w3.org/2008/07/09-wsc-minutes.html#action04]
<trackbot> Created ACTION-492 - Contact ebay about paypal web authoring best practices [on Phillip Hallam-Baker - due 2008-07-16].
Mez: other exemplars?
yngve: wells fargo?
Mez: any more?
yngve: one thing - handling of personal details on a web page - is that something we want to touch on
<Mez> johnath: guidelines for storing information on backend, can spiral badly into laws
yngve: I was thinking more about how those are solicited, but it's a fine line to walk
Mez: examples?
yngve: addresses, credit card information - how is that requested, how is it submitted?
<Mez> jonath: hard to test, otherwise might be compliant, phone numbers might be benign
<Mez> ... should only say something in generic terms if we say anything at all
<Mez> ... what is personal is a business decision
Mez: Good point - companies will have internal guidelines about that stuff, carefuly defined and controlled
<Mez> johnath: not sure this is great
<Mez> ... most current guidelines are concerned with interaction between client and web site
<Mez> .. mixed mode, redirect
<Mez> ... what about sql injection, sanitizing cgi parameters
<Mez> ... pretty sure we don't want to go there
<Mez> ... not sure we're right, but it could be a gap
Mez: I'm trying this one on
myself, and leaning in the negative direction.
... not because it isn't important - it's a huge issue
... browsers are also doing a meet in the middle on that - IE
just announced XSS filtering
<Mez> and then there's caja
PHB2: it's a long list of
problems, but 99% of them come from one problem - mixing data
and code
... there are ways that you can build your site so that it
isn't vulnerable to such an attack
Mez: while I agree that there are things that can and should be done, it sounds outside the range of experience reflected in our group
<Mez> johnath: agree with phil; there's something that's at base in this
<Mez> ... don't drop cgi form/url without sanitizing it
Mez: yeah, let's follow that a
bit
... so Sanitizing inputs to the database is safe, but not
always more appropriate
... for example, backend database for domino emails served by a
web client and a fat client (eclipse-based)
... the fat client has controls on things like signatures that
the web content doesn't. Sanitizing on input would restrict the
flexibility of the fat client, which has a security model and
could do smarter things
PHB2: seems to me that one of the advantages to having this language in the standard is that it encourages people to develop tools that help the web site developers confirm their implementations are compliant
Mez: there are testing tools out there
<Mez> also IBM Rational App
<Mez> AppScan
<Mez> I believe Fortify does some code scanning
johnath: I can write a subsection that tries to say, in broad strokes, what we consider to be obvious best practice around sanitizing user data
<Mez> johnath: all 2119'ed
<Mez> ... should this be guidelines to consider instead of conformance doc?
<Mez> johnath: hard to talk about conformance testing - make sure it's safe
<Mez> johnath: probably all aspects of the document
<scribe> ACTION: johnath to write up guidelines section related to sanitizing user data [recorded in http://www.w3.org/2008/07/09-wsc-minutes.html#action05]
<trackbot> Created ACTION-493 - Write up guidelines section related to sanitizing user data [on Johnathan Nightingale - due 2008-07-16].
<scribe> ACTION: mez to contact rob y about web authoring guidelines and security [recorded in http://www.w3.org/2008/07/09-wsc-minutes.html#action06]
<trackbot> Created ACTION-494 - Contact rob y about web authoring guidelines and security [on Mary Ellen Zurko - due 2008-07-16].
Mez: other agenda topics for next week?