See also: IRC log
Approve this agenda?
Accepted.
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
Accepted.
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 discuss.
... 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 true.
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
vulnerable.
Stuart: I see four good practice notes
Noah: I think the good practice
notes are pretty vague so it's hard to tell.
... 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 too.
<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 GPN(s).
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 field.
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 key.
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 community?
<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 caveats?
-> 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 developers.
<scribe> ACTION: Stuart to summarize discussion to Mary and make plans for further progress. [recorded in http://www.w3.org/2001/tag/2007/06/25-minutes#action01]
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: http://lists.w3.org/Archives/Public/www-tag/2007Jun/0092
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 <banana>.
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 ... SCRIBE MISSED
David: Accept minus defined or something like that.
Noah: We also have to note that different documents may have different notions
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 work.
... 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 proposed.
... 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 there.
... 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 those?
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/2001/tag/2007/06/25-minutes#action02]
Stuart: Thank you for filling in the form, but the database is down today.
Henry: Database updating today, wait until tomorrow.
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
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
themselves.
... 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 power?
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 correctly.
... 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.
Stuart: If you have items for next week's agenda, please send them to me.
Thanks and we're adjourned.