- 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
W3C[1]
- DRAFT -
Techical Architecture Group (TAG)
25 Jun 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Rhys, Stuart, Noah, Raman, Henry, David
Regrets
TimBL
Chair
Stuart
Scribe
Norm
Contents
* 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
----------------------------------------------------------------------
Administrivia
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
Approve minutes from 18 June 2007?
Accepted.
passwordsInTheClear-52
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/2007/06/25-tagmem-minutes.html#action01[4]]
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
XMLVersioning-41
<Noah> Discussing Noah's note at:
http://lists.w3.org/Archives/Public/www-tag/2007Jun/0092[5]
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/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
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.
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
http://www.w3.org/2007/06/25-tagmem-minutes.html#action02[8]]
[NEW] ACTION: Stuart to summarize discussion to Mary and make plans for
further progress. [recorded in
http://www.w3.org/2007/06/25-tagmem-minutes.html#action01[9]]
**
[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
log[11])
$Date: 2007/06/26 16:17:07 $
Received on Tuesday, 26 June 2007 16:19:41 UTC