W3C home > Mailing lists > Public > www-tag@w3.org > June 2007

TAG Minutes 25 June 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 26 Jun 2007 12:19:27 -0400
To: www-tag@w3.org
Message-ID: <87fy4eelio.fsf@nwalsh.com>
See http://www.w3.org/2001/tag/2007/06/25-minutes


                                   - DRAFT -

                       Techical Architecture Group (TAG)

25 Jun 2007


   See also: IRC log[3]


           Norm, Rhys, Stuart, Noah, Raman, Henry, David





     * Topics
         1. Administrivia
         2. Approve minutes from 18 June 2007?
         3. passwordsInTheClear-52
         4. Review request for Enabling Read Access for Web Resources
         5. XMLVersioning-41
         6. Vacation scheduling
         7. Future directions
         8. Any other business.
     * Summary of Action Items



   Approve this agenda?


   Next telcon: 2 July

   Raman to scribe.

   Noah and David give regrets for 2 July

   Stuart: Under any other business, I'd like proposals for agenda items for
   next week

  Approve minutes from 18 June 2007?



   Stuart: What were the obstacles to making progress on this finding?
   ... I'm not sure we have a date where Mary Ellen (IBM) can meet with us to
   ... Could we meet on a day other than Monday?

   Norm: I'm happy to, as long as I don't have a conflicting call.

   <Noah> Please note that I am unavailable for the first two weeks of July,
   regardless of day.

   Stuart: I've asked her to suggest an alternate time.

   Welcome Ed

   Henry: I haven't reviewed it recently, but I recall that the sticking
   point was that the finding suggested user agents do something they'd
   flatly refuse to do.
   ... We wanted user agents to warn people when they send passwords over
   http. Then it became clear that there are secure JavaScript-based
   implementations that do use http. So it wasn't going to be acceptable to
   give warnings when they weren't necessary.
   ... My memory is we got there and we stopped.

   Ed: I think we discovered that Yahoo was downloading an encryption key
   within the JavaScript. So the warning would apply there when it wasn't

   Raman: The other thing to do would be to drop the finding.

   Henry: I don't agree. There was a lot of sentiment that we ought to be
   saying this.

   David: Can we phrase it differently? Maybe saying that if the browser is
   aware that the password will be sent in the clear, because it's using
   standards, then the warning should be displayed.
   ... That would narrow the scope, but...

   Ed: How can you tell? In both cases, the standard password field is used,
   but in the JavaScript case it's encrypted before its sent. The browser
   can't tell.

   Noah: Does Yahoo encrypt the password field in place. When I hit "submit"
   it runs some JavaScript and encrypts the field. Does the browser think I'm
   submitting a password

   Henry/Ed: Yes

   Stuart: So it's the JavaScript that does the posting.

   Ed: Yes.

   Noah: I've been lukewarm for a variety of reasons, but it's not clear to
   me that the problem Henry raised is real.

   Norm: I think the browser really is submitting the form after the
   onSubmit, so the browser really can't tell.

   Ed: Right.
   ... We did find that the JavaScript technique used by Yahoo was

   Stuart: I see four good practice notes

   Noah: I think the good practice notes are pretty vague so it's hard to
   ... We're really saying "don't do anything that doesn't meet your needs"

   Ed: I'm willing to tell servers that they should change.

   Stuart: I interpreted the first good practice as simply meaning that the
   typed password shouldn't be displayed on the screen when you type it.

   Noah: That's not what I thought. I thought it was about avoiding point 2.

   <Rhys> FWIW I read it the way that Noah read it

   Stuart: I think in the Yahoo case, you could argue that they've covered
   the first three points.

   Henry: That's precisely the problem. The user agent can't tell that, so
   it's going to warn the user.

   Raman: The other practice you see frequently is a clear text http:
   submission that's redirected to an https: URI. That's totally insecure

   <Noah> The concern I'm raising as that, even among the few of us on the
   phone, we're getting pretty different answers about what these practice
   notes mean. Stuart reads the first one as saying: don't prompt for PWs in
   a way that will display them on the screen. If that's what we mean,
   shouldn't we say it that way?

   Stuart: Does anyone have ideas about how we make progress?

   David: I thought there had been some suggestions for limiting scope, I
   thought it made sense to incorporate those suggestions.

   <Noah> FWIW, I read the same GPN as "don't send HTML and/or JavaScript to
   the client that would cause it to violate rule 2, I.e. to send the
   password back up in the clear."

   David: I think these are statements that are worthy of being said. I
   really want to find a way to proceed.

   Henry: I think we can proceed by removing the teeth. No longer put any
   onus on user agents.

   Ed: But isn't the whole point to protect the user?

   <Noah> I'm fine saying either or both of those, but I think we should at
   least make sure that those sorts of ambiguities are removed from the

   Ed: If we don't tell them, how are they going to know?

   Stuart: Henry's point is we don't know how to tell.

   David: Sure, but we could say something about the JavaScript case.

   Raman: JavaScript is noise here, it's only a hook that latches on.

   Ed: If you don't want to trigger the alarm, then don't call it a password

   Henry: We could also leave all of the text as it is, but we make a
   footnote that says user agents can only reliably determine if a password
   is being sent in the clear if no scripts are used.

   Raman: All that HTML garantees you with input type=password is that the
   characters you type won't be displayed.

   Henry: Right, we're trying to get UAs to go one step further: warn users
   if the form is submitted in the clear.

   Raman: Maybe we can say: things that aren't shown in the clear on the
   screen shouldn't be sent in the clear over the wire.

   Henry: Right. Now how do we state this as an injunction that UAs can
   reasonably implement.

   Norm: I also have some sympathy for the position that false negatives are
   safer than false positives.

   Ed: A whole lot of login pages have all sorts of JavaScript so if you
   excluded this warning on pages with JavaScript you'd limit a lot of cases.

   Henry: I'm only suggesting that onSubmit should be the trigger

   Some discussion of when scripters usually do consistency checking.

   Conclusion: yeah, maybe that won't fly.

   Ed: I'd be happier just saying that some sites are doing it
   wrong...because you can decrypt (some of) the JavaScript attempts

   Stuart: In principle they could have done it right with half of a public

   Ed: It's hard to do it too strongly because the entire program that does
   the encryption has to be in the JavaScript.

   Stuart: I'm saying that in principle it could have been done strongly.

   Ed: If we have a password field, we ought to warn people when they may be
   used insecurely, that's my point.

   Stuart: What's the objection?

   Ed: The teeth.
   ... Noah, you're arguing that in some places passing passwords in the
   clear is OK.

   Noah: Yes, but that's not really my main concern.
   ... Stuart and I read the first good practice note and came to different
   conclusions about what it meant. I think that's the problem.
   ... Maybe we want to tell both stories. My real problem is that I think
   you can go two ways: one is to tell an extremely broad story that isn't
   very detailed; the other is to tell a more detailed story. But in that
   case, it's hard to get the details right.
   ... I'm trying to see if we can find a middle ground.
   ... But I've already said I won't belabor these concerns if I'm the only
   one who has them.

   Henry: Is this a viable finding as it is? Without the teeth? If we added
   more caveats about lightweight passwords?

   <Noah> Should we ask: is there any one GPN in this that's suitably
   unambiguous, and that we think would be really good advice to the

   <Noah> Is there a 2nd one?

   <Noah> Stir until done (or dead).

   Stuart: Straw poll: viable as it is, stripped of teeth, or with more

   -> David: 1/3; Henry: 2/3; Noah: I'd like it be less ambiguous, but
   abstain; I think it's borderline worthy of publication; Norm: 3; Raman:
   I'm confused, I'm not sure the results are worthy of a finding

   -> Stuart: I'd like to say something with teeth, but I'm not sure what
   that is.

   Stuart: I think this gives me a better idea of what to tell Mary

   <Noah> To be clear, I'm not against doing work towards trying to publish,
   I'd just like to see the advice get clearer, and then I'd like to be sure
   that it's targeted at the real pain points or areas of practical risk.

   Rhys: I don't have any of the history, I think it would be nice to say
   something, but the world wouldn't collapse if we didn't.

   Stuart: Raman, can you remind me of the conversation you had with Mary?

   Raman: She'd like the TAG to say something, she was disappointed that we
   hadn't made more progress, and asked if she could help.

   Stuart: Ok, I'll write to her and see if we can schedule something.
   ... Ed, do you still want to be engaged?

   Ed: Yes, I'd like to contribute if I can .

   Some discussion of Ed's experiences discussing this with the IE

   <scribe> ACTION: Stuart to summarize discussion to Mary and make plans for
   further progress. [recorded in

  Review request for Enabling Read Access for Web Resources

   Stuart: I don't have a huge amount of background or context to share. It's
   a pity Dan isn't here.

   Noah: I think this is an attempt to put some declarative mechanisms behind
   what you see being done with xmlHttpRequest regarding who's allowed to
   pull down what content.

   Rhys: They describe it as extending the browser sandbox.

   Stuart: Anyone willing to take a review pass?

   David: I've asked a couple of our security folks to take a look.
   ... I'd like a little more time before committing to a review.

   Norm: I'm interested, but I'm not sure I have enough real-world experience
   with the actual technologies involved.

   Stuart: Should I leave it a week?

   Yes, apparently


   <Noah> Discussing Noah's note at:

   Stuart: I put Noah's message on the agenda along with some comments by
   Olivier Thereaux

   <Noah> Key points:

   <Noah> * IF the language completely ignores extension content, then
   defined/accept tells a powerful story. Each text in the accept set has an
   equivalent in the defined set.

   <Noah> * BUT: many languages we use all the time define important
   non-ignore generic semantics to extension content (e.g. it's stylable,
   it's scriptable). You can tell the difference between <banana> and <fish>
   even if HTML doesn't call them out.

   <Noah> * Using the PHTML+PCSS example, Tim claims that all documents,
   including with <banana> are in the defined set. So, it's not clear to me
   whether defined/accept offers usef

   <Noah> * Using the PHTML+PCSS example, Tim claims that all documents,
   including with <banana> are in the defined set. So, it's not clear to me
   whether defined/accept offers useful insight into the versioning that
   happens if PHTML+PCSS version 2 were to define a particular semantic for

   Noah summarizes the bullets above and email thread

   Stuart: One question: I keep tripping over whether or not people think the
   defined/accept sets are disjoint or overlapping.

   David: I thought it was fairly clear that the accept set is a superset of
   the defined set.

   Noah: I thought it was just the outer ring, the difference.
   ... If that confusion remains, we need to settle on consistent terms
   pretty soon.

   Henry: In the bulls-eye diagram, if the center, labeled A, and the ring
   around the center B, it's not clear if B *includes* A or not.

   <Noah> Anyway, we need to keep in mind that my email, and the summary
   above, is written as if accept set and define set are disjoint. I have no
   strong religion on which way we go, as long as it's made clear.

   David: I thought that since we speak of superset and subset relationships
   it was clear.

   Henry: I think that's right, but you also need a name for the ring, the
   set difference.

   David: I've brought up the naming issue a couple of times, but we haven't
   settled on a name.

   Noah: There are three interesting concepts: a document that's acceptable
   but not defined, a document that's defined, and a document that's ...

   David: Accept minus defined or something like that.

   Noah: We also have to note that different documents may have different

   David: I think we should proceed to talk about what happens if banana gets
   defined. I think that really happens.

   Noah: Do you buy the formulation that I ascribe to Tim: If I start with
   the combination of HTML+CSS and I have a banana, Tim says they're in the
   defined set because CSS can style them.
   ... If every document is in the defined set, then I'm not sure this is
   going to help much.

   David: I have to think a bit, but my intuition is to not put the banana in
   the defined set.

   Noah: As long as you agree with Tim, and say it is in the defined set,
   then I get to come full circle pointing out that defined/accept don't
   ... Or the other way is to say that you and Tim don't agree. Then I come
   back to not thinking that I'm hearing a consistent story.
   ... The only consistent point is that the defined set is more-or-less what
   you're expecting.
   ... I think we need clarity on this before we go much further.

   David: I think I'll add what you've done to the terminology section and
   see how it falls out.

   Noah: Where I'd like to go is: step 1, figure out the terminology for the
   three sets and rewrite what I wrote using that terminology.
   ... I think we also need to decide if we care about the use case I
   ... We could decide not to answer the question of HTML+CSS, but I think
   that would be unfortunate.
   ... I think it might make sense to solve the general case first and then
   work on the special case.
   ... It's crucial that you can style bananas differently than fish.
   ... My intuition is that if we get that right, the ignore case might just
   fall out.

   Stuart: I was looking at Noah's examples. Banana, particularly in this
   with-styling case, turns up in a couple of ways.
   ... Sometimes as a tag with angle brackets and sometimes as free text in
   the styling.
   ... I find myself wondering how much different these two cases are.

   Noah: I've been pushing on the special case of markup too. I think we
   should just talk about strings first and treat markup as a special case.

   Stuart: What I came to has the feeling that the style language is a bit of
   a meta language. It introduces new vocabulary. I wonder if the more
   generic thing is to look at languages that can introduce new vocabulary.

   <Noah> Well, maybe not "just" strings, but I have said I tnink there's
   value in thinking about the general text case early in the game. Still,
   there's a lot about markup and other regular tagged structures that's
   special and important for versioning, I think.

   Stuart: We provide ourselves with factories for adding new vocabulary.

   David: I really think that this is good. The issues around generality are
   exactly right.
   ... If you're going to have a bare bones strategy, ignoring unknowns looks
   promising, but then you have to answer the question about what ignore
   means and what unknown means.

   <Noah> David: We're on the issue of "just what do we mean by ignore"?

   <Noah> Yes, exactly Dave.

   David: Ignore is basically shorthand for "don't break under validation"
   ... If you get some extra stuff that you don't know about, the one
   restriction you have is that you can't break under validation.

   <Noah> Not sure I'd put it that way. I think the word "ignore" is very
   misleading for that. "Accept" is perfect for it.

   David: So HTML ignores it, but retains it for styling.

   <Noah> I like: "Accept, but with a generic semantic."

   David: It's really scoping the meaning to "don't fail validation". Once
   you've determined that something is unknown, you have to decide what to do
   with it. Early versions of HTML used to discard unknowns.
   ... Now the DOM retains them. There are at least three flavors: ignore and
   discard subtree; ignore and retain subtree; ignore and preserve.

   <Zakim> Noah, you wanted to say "ignore and retain is oxymoronic"

   David: Two of these are in the finding, but the preserve case isn't really
   talked about that much.

   Noah: I like the whole meat of where we're going, the problem I have is
   about talking about ignoring and maintaining. I think maybe we're trying
   to work to hard to preserve the word ignore.

   <dorchard> "Must Accept Unknowns"?

   Noah: Maybe "accept" is a better word. You want to accept the unknowns,
   you're not ignoring it.
   ... I would suggest that "ignore" be reserved for the special case where
   there really is an equivalence with a document where it wasn't really
   ... Comments and white space, for example, are often just ignored.
   ... In the "outer ring" the question is, is there a completely equivalent
   document in the inner ring?
   ... Let's find the words that really describe what we mean.

   Stuart: What you're proposing then is that David work this into the
   terminology section.

   David: Noah, you had a bunch of stuff written on pieces of paper, do I get

   Noah: Yes, I'll try before I go on vacation for two weeks (in four days)

   David: I've got vacation plans in late July through 13 August.

   Noah: I'll try.

   David: I want to get this done before I go on vacation

   <scribe> ACTION: David to update all 3 documents in versioning finding
   [recorded in http://www.w3.org/2007/06/25-tagmem-minutes.html#action02[6]]

  Vacation scheduling

   Stuart: Thank you for filling in the form, but the database is down today.

   Henry: Database updating today, wait until tomorrow.

  Future directions

   Stuart: We started this in Mountain View. Should we try to continue now?

   David: Yes.

   Stuart: So how do folks think Web 2.0 changes things?

   David: We had an outline at Google, right?

   <Stuart> http://www.w3.org/2001/tag/2007/05/webarch2-outline[7]

   David: I think we've touched on one of the things, the incredibly heavy
   use of JavaScript means that browsers don't have to rev so often.

   Raman: You can view this as the browsers have essentially frozen. There's
   a turing complete language in the browser, so that's where all the
   development takes place.

   <Noah> Well, seems to me like a bit of hype around "Rule of Least Power"
   wouldn't hurt.

   David: So then you look at the frameworks like DoJo.

   Raman: Everything is being implemented at the document level. What would
   this have looked like in '94? You probably wouldn't have something
   fundamental like httpRequest and Post. Scripters would have invented that
   ... Because the GET and POST framework exists, that's what got used. But
   extending vocabularies aren't extending those frameworks anymore, it all
   depends on the particular libraries that you use.

   David: I think that this all had to happen in the order it did, you need
   the simplicity and rigor of the uniform interface and REST in order to
   provide a platform for the JavaScript. You needed the browser to be in
   every desktop.

   <Zakim> dorchard, you wanted to ask Noah about his review coment

   David: People didn't have GUI desktops in '94.

   <Zakim> Noah, you wanted to say, what do we need beyond rule of least

   Noah: I think this is interesting and important. But we already have
   findings that take a position on some of these issues.
   ... The least power finding talks about some of these tradeoffs. Maybe
   part of what we want to do is refer to that.
   ... We also have a finding that talks about using the HTTP verbs
   ... Google maps is madly doing GETs and POSTS but you don't get a
   constantly updated URI.
   ... I think we have some of the important pieces and findings already. How
   do we get people to have the right discussion about these issues with
   respect to Web 2.0.

   Stuart: Does anything fundamentally change about the nature of a resource?

   Raman: I think that has happened. The intermediate stages no longer have a
   URI; the apps are more RESTful than web services, the use URIs
   intelligently but they don't use it everywhere.
   ... The app developer decides which parts of the state are exposed in
   URIs. The ones that aren't, just aren't available.

   <Noah> I agree that the Web 2.0 stuff is in many cases more RESTful than
   most Web services. In many cases, though, the user agent doesn't make it
   easy to show the user the continually changing URI for what they're
   looking at.

   <Noah> If the typical user can't get it, then he or she can't bookmark it,
   email it, etc.

   Raman: In the early world, there was a clean 1:1 mapping between state and
   URI; now that's up to the app developer.

   Noah: My personal feeling is that the value of URIs haven't changed.

   Raman: I'm not sure there's a right or wrong, all we can do is list pros
   and cons.

   Noah: Yeah, but that's true of the whole web arch, but we don't say that,
   we say SHOULD and MUST.
   ... Being a sophisticated user, I know how to use the "bookmark this"
   link. I think the fraction of users that get it is probably low. I wonder
   if osme of that isn't a matter of user agents just not making it easier to
   get continuous update.
   ... I think it's valuable to be able to mail the link.
   ... It's worth addressing, I think.

   Stuart: We're out of time.

  Any other business.

   Stuart: If you have items for next week's agenda, please send them to me.

   Thanks and we're adjourned.

Summary of Action Items

   [NEW] ACTION: David to update terminology section [recorded in
   [NEW] ACTION: Stuart to summarize discussion to Mary and make plans for
   further progress. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/2001/tag/tag-weekly
   [3] http://www.w3.org/2007/06/25-tagmem-irc
   [4] http://www.w3.org/2007/06/25-tagmem-minutes.html#action01
   [5] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0092
   [6] http://www.w3.org/2007/06/25-tagmem-minutes.html#action02
   [7] http://www.w3.org/2001/tag/2007/05/webarch2-outline
   [8] http://www.w3.org/2007/06/25-tagmem-minutes.html#action02
   [9] http://www.w3.org/2007/06/25-tagmem-minutes.html#action01
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.128 (CVS
    $Date: 2007/06/26 16:17:07 $

Received on Tuesday, 26 June 2007 16:19:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:52 UTC