Admin

NM: DA, are you prepared to scribe next week

DA: Regrets for next week

NM: DanC, can you scribe next week?

DC: Yes

NM: Minutes for 4 Feb? I've read them, anyone else?

<DanC> +1 approve http://www.w3.org/2001/tag/2010/02/04-tagmem-minutes

<DKA> +1

NM: Minutes for 4 Feb approved
... Minutes for 28 Jan are still pending minor updates from LM

http://www.w3.org/2001/tag/2010/01/28-minutes

ISSUE-58 & ACTION-163: Sample catalog

HT: This is done. I used the official Oasis format catalog + some stuff. Contacted head of W3C sys team. Now stalled trying to figure out where to put it, but I think my action's complete.

<Zakim> DanC, you wanted to ask if anybody has picked it up and used it yet

DC: Anyone picked it up?

HT: Don't think so.

DC: I'm not comfortable saying the TAG's work is done.

HT: My action's done...new one would be welcome.

DC: ScalabilityofURIAccess (sp?) issue is still open.

NM: Do we really understand who will find this useful
... If we think this is useful and will reduce the bogus traffic
... that would be good
... but I'm not convinced that making a catalog available will fix the problem

DC: One source of problem is a Java library, if that library was fed a catalog, life would improve

NM: Not convinced it's one library
... distributing is hard
... only one data point
... Deeper architectural point: Lots of accessing of a URI is not a violation of the architecture of the Web
... My company doesn't run a proxy, for example, because it's cheaper to pay for more bandwidth than to pay for and maintain a proxy

<masinter> Consequence of design pattern advocated by TAG that wasn't necessarily taken into account.

DC: Isn't it obvious that fetching the same thing 1000s of time when it isn't changing is a bad thing?

NM: Not to me -- it's a matter of economics

JK: Is the etag set right?

DC: Yes, +1 year
... I was asking NM if it was reasonable

NM: The etag is there as a service to the client, not a requirement

<DanC> (yes, it's a matter of economics, and the economics here look pretty darned unreasonable, to me.)

LM: The design pattern of using http: URIs for static resources interacts with services which don't work without hidden assumptions about service guarantees

<NoahM> If it's against the rules to make frequent access, then that should be documented along with the pertinent parts of the protocol

<NoahM> I don't think the failure case involves catalog. The failure case is just a URI that's getting a lot of access. The catalog may or may not help as a solution.

LM: There is an architectural issue here
... The pattern of using http: URIs makes some assumptions
... which aren't always valid

<NoahM> I don't think this is primarily about XML Namespaces either. It's any central resource, like HTML DTDs.

LM: Not sure where the fix should go

DC: Compare software -- we expect to fetch once and install locally

LM: Right -- when specs are published including URIs any assumption about not refetching should be made explicit

NM: I don't believe that is present in specs today
... How could we change that now?

<masinter> first thing we should do is make implementation considerations when URIs are expected to not be accessed frequently

NM: People have made assumptions which aren't consistent with a change

<Zakim> NoahM, you wanted to ask whether we know whether anyone finds it useful. and to respond to Dan

NM: It would be, for example, very expensive for a large company to support caching on the necessary scale

LM: Recommendations (which haven't yet been made) have to be in place before fault can be assigned

NM: But e.g. my employer has been faulted
... and told that what they are doing is broken

<masinter> if you used URNs instead of http: URIs, there would be less of an expectation of maintaining a cache

HT: Sorry, nobody has said that anybody is at fault. The W3C has said we are going to stop serving these documents to these requests.

NM: I believe large chunks of my company are being blocked.

HT: Not lately.

NM: Hmm. I've had one or two recent complaints, but it's quite possible that it's for other reasons.

<NM:> FWIW, I think the catalog is a likely a useful step. I just think we've exposed a really interesting architectural question about the Web that's worth tracking.

HT: You might reasonably say "what's the justification for W3C doing this?" I set up a local catalog properly, because some of the requests in my software were being bounced.

<DanC> (one response is: "I gave you a copy yesterday with a promise that it's good for a year; that suffices for quite some time.")

NM:Stepping back from any particular DTD, there is an interesting architectural issue

NM: In general, I publish a URI, do I take on any high traffic service obligation

<johnk> a URI is an identifier

NM: and if you fetch a copy, do you have an obligation not to do so at a high rate?

<johnk> is there a guarantee of any service on a URI?

NM: If you fetch maliciously, obviously that's bad, but there's no claim of malice in the current cases

trackbot, close ACTION-163

<trackbot> ACTION-163 Coordinate with Ted to build a sample catalog closed

<NoahM> I think the question of whether clients have an obligation, e.g., to run proxies, is a really interesting one. Would love someone to take it up.

<DanC> issue-58?

<trackbot> ISSUE-58 -- Scalability of URI Access to Resources -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/58

<NoahM> Anyone else interested in diving in on some other aspect of ISSUE-58?

<NoahM> Silence.

LM: Is this an open issue?

NM: Yes

<DanC> (it doesn't seem to have a shepherd)

LM: Issue has no shepherd

NM: Issue still open
... Shepherd volunteer?

LM: Not just scalability, but also implication of using URIs with implicit expectation of caching/proxying

NM: DA?

DA: I'm neutral, so sure

LM: DA, please review the Issue and confirm that it covers all the bases discussed today

ACTION DA to review ISSUE-58 and suggest next steps, due 2010-03-03

<trackbot> Created ACTION-390 - Review ISSUE-58 and suggest next steps, due 2010-03-03 [on Daniel Appelquist - due 2010-02-18].

<DanC> action-390 due 3 March

<trackbot> ACTION-390 Review ISSUE-58 and suggest next steps, due 2010-03-03 due date now 3 March

<DanC> action Noah prepare March 2010 ftf agenda

<trackbot> Created ACTION-391 - Prepare March 2010 ftf agenda [on Noah Mendelsohn - due 2010-02-18].

<DanC> action-391 due 8 March

<trackbot> ACTION-391 Prepare March 2010 ftf agenda due date now 8 March

ACTION-345: Widget / Phonegap Convergence

NM: I was asked to do some factfinding
... What is phonegap and will there be convergence?

<NoahM> http://lists.w3.org/Archives/Public/www-tag/2010Feb/0045.html

NM: I sent email
... I don't think further action is required

DC: I read this, no obvious pblms
... For example, no obviously incompatible Geo API

NM: Yeah, there's some vague indication of goodwill, but no actual guarantee in that area

DA: As I understand it, phonegap are headed for convergence with W3C widget specs

<masinter> isn't this just standard (or reminding) W3C working groups that the expectation is they do their work with agreement of the community, not just working group members?

DA: They are participating in the DAP work

<DanC> (phonegap participates in DAP? I think that's news to me. good.)

DA: No problems here . . .
... A good example of where an open source effort has been reached out to and involved into W3C work

LM: There is an issue about IETF liaison wrt protocols such as calendar. . .

NM: We are backing into the API convergence issue

<DanC> (which IETF WG(s), larry?)

<masinter> contacts API should correlate with LDAP

DA: I think phonegap is a red herring wrt that issue

<masinter> (looking for email on W3C/IETF liaison list)

<DanC> Coordination issue: vCard, iCalendar vs JavaScript contact and calendaring APIs Thomas Roessler (Wednesday, 27 January)

<masinter> vcarddav, calsify

<masinter> http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Jan/0001.html

NM: I'm interested in the use case of html, css, javascript with apis, e.g. to help take a picture
... could be hosted in a widget, or by phonegap

close action-345

<trackbot> ACTION-345 investigate possible convergence of phonegap and w3C widgets closed

LM: I copied the TAG on email relating to the IETF liaison issue

<masinter> just wanted it in the minutes, it's fine not to discuss

ACTION-367: Microdata bug report to HTTP WG

NM: Small management action, to make sure they logged our input properly

<masinter> action-367?

<trackbot> ACTION-367 -- Noah Mendelsohn to ask the HTML5 chairs to treat our 8220 bug as input to the poll, specifically as "An objection to keeping Microdata in", cc to www-archive@w3.org -- due 2010-02-10 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/367

NM: I sent a note, HTML WG co-Chair acknowledged receipt and said they would take our input

<NoahM> Note from Noah to HTML 5 chairs: http://lists.w3.org/Archives/Public/www-tag/2009Dec/0099.html

<NoahM> Response from chair: http://lists.w3.org/Archives/Public/www-tag/2010Jan/0001.html

LM: I have individually objected to the publication of the microdata spec as an HTML WG work item, as being out of scope
... I would welcome others joining

<masinter> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220 says as its first bullet "It is out of scope"

HST notes background is that wrt the original issue, microdata section has been removed from the HTML 5 spec.

close action-367

<trackbot> ACTION-367 Ask the HTML5 chairs to treat our 8220 bug as input to the poll, specifically as "An objection to keeping Microdata in", cc to www-archive@w3.org closed

<masinter> the chairs didn't accept the TAG input that it is out of scope

<DanC> (masinter, http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220 shows the TAG taking the position that it's out of scope)

ACTION-278: Draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case

JR: Have people read [the email]?

http://lists.w3.org/Archives/Public/www-tag/2010Feb/0051.html

DC: I've read some but not all

NM: Another thread started with unhelpful title: http://lists.w3.org/Archives/Public/www-tag/2010Jan/0087.html

<johnk> I've read the thread

<NoahM> I've read all the threads, but there's a lot of substance, and I've been in all day meetings and/or out of office all week. So, haven't given it the attention it really deserves.

JR: Began at F2F, discussion of capability-based security

JR: Someone remembered the Metadata in URIs finding, which said "don't put confidential information in URIs"
... but people produce not-wanted-to-be-completely-public URIs all the time, e.g. unsubscribe links
... I've written up the Google Calendar case and the unsubscribe case
... I wrote some text which I thought was quite conservative, trying to make peace between the finding and unsubscribe case

<NoahM> I find the Google Docs case to be in some respects most evocative, followed by Calendar, because that happens to be (relative to my personal preferences), in decreasing order of concern regarding disclosure. I have things in docs I >really< don't want to have leak. Feel almost as strongly about cal, a bit less so about unsubscribe. FWIW.

<DanC> (hmm... unsubscribe links are sorta more complicated than necessary, as they involve the ability to read email at some address.)

<NoahM> Exactly, Dan, presuming that the links were emailed.

JR: Tyler Close responded saying we had not gone far enough, we ought to encourage this practice

JR: I don't see how to move this forward

AM: Can you summarise where the gap is?

JR: On the one hand: URIs can be protected, and should be when they can and should be
... On the other: exposure of URIs is too difficult to manage/control

<NoahM> For me, the issue is changing the rules post facto. We'd be retroactively declaring that anything that "leaks" URI is broken.

LM: There are limited circumstances where secret URIs are good for something. We need to be careful what circumstances are, how careful you need to be, etc.
... The process of following up will involve pushback on the notion that these are in general good practice. We're not at an impasse -- we're doing the necessary analysis of security vulnerabilities.

<masinter> this is the kind of analysis needed when you do a security analysis: what are the threats, and how do you mitigate against them

<Zakim> DanC, you wanted to give my preference: to integrate http://lists.w3.org/Archives/Public/www-tag/2010Feb/0081.html into a revision of the metadata-in-URIs-finding

DC: I've read this a bunch of times, Tyler's suggested text [....] looks good to me

DC: Justification comes down to cross-site request forgery attacks

<NoahM> Dan, so you don't have a problem with Tyler's suggestion that:

<NoahM> A user-agent MUST NOT disclose representations or URIs, unless either explicitly instructed to do so by the user or as legitimately directed to by presented content. Since the user may wish to keep this information confidential, the user-agent must not assume it can be revealed to third-parties.

DC: You can't do forms the way I have been
... The nifty thing about forms the way I did them was that the form could be static
... That doesn't work, you have to put a unique token in each form instance you serve
... to protect against cross-site request forgery

NM: Quote above OK?

DC: Yes

NM: I agree with LM -- this is about doing the security analysis, figuring out where the limits are.
... But I think there are some changes which are difficult or impossible to make retrospectively
... see the quote above
... People have been writing UAs for years, how can you change your advice after all this time?
... Have we really been wrong all this time?
... And what about the reference to 'user agent'? URIs get moved via email, does that make email clients UAs?

DC: Some existing UAs follow embedded image links, thereby giving away that the mail is being read, others don't

NM: My point is that talking about 'UAs' doesn't help with understanding the mail-based cases

LM: I had a particular experience of posting access logs which inadvertently violated other peoples' applications

<DanC> (putting the logs in public is a violation of the security section of the HTTP spec, I'm pretty sure.)

LM: Where is the rule that you shouldn't publish server logs?

<DanC> http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.1

<NoahM> Yeah, my concerns with the server case is that the server admin tends to be acting on behalf of the application

<Zakim> DanC, you wanted to suggest that the rules are changing because we didn't know the threats a long time ago. (a la my understanding of how forms work)

DC: Yes, I think we can change the rules, because the threat population has changed

NM: So agents which leak in this way today are conforming today, but we can try to move to a situation where a new agent which does this is non-conforming

DC: The general rule is that UAs act on behalf of users
... If the UA is acting on behalf of the blackhats, it's not conforming

NM: What about the web archive example? Who is the [non-conforming] UA there?

DC: I don't know what example you are referring to

<DanC> (I didn't say "conforming"... cuz the "user agents act on behalf of users" isn't in a spec; it's just common sense.)

NM: Use case was an email Tyler Close sent to www-tag including a 'secret' URI, which he said was now open to www-tag subscribers
... but actually because it was archived, it became public to the whole world
... is anything broken?

DC: No, nothing is broken -- he knew it was going everywhere

LM: No, he thought it was going to the subscriber

<DanC> (the w3c web site does a round trip to make sure people know their mail gets publicly archived. of course there's the risk that he got confused, but it's a pretty clearly disseminated policy)

NM: But [he should have known] there was software involved that would publish widely

<Zakim> johnk, you wanted to note that I certainly think that rule about disclosing is likely unenforceable

JK: I think Tyler's communication to www-tag is not secret.

JK: You shouldn't use a secret URI there.

<DanC> (no opportunity for revocation? I've pointed out N times that there is, Larry)

LM: The security you get from passwords is difference from the security you get from URIs

LMM: There are common patterns for mitigating the risk of exposure, but the risk of recovery are different. The paths of disseminiation for URIs including things like accidental dissemination of log files. There are greater risks of discovery, they are not the same. The paths for dissemination include log files (accidentally revealed) for URIs, but not for passwords

<DanC> (I'll buy "different risks" but not "greater risks")

JK: I'm not seeing a difference, just a continuum

LM: The unsubscribe link is not a problem in a log file, because once you've used it, it's useless

NM: In a spec. which introduces passwords, there are a whole bunch of discussions you expect about managing distribution and protection
... as is the case with capabilities
... in distributed cap. systems as well as local ones

JR: No

<DanC> (spec says who's supposed to have access to my passwords? show me one.)

NM: My experience differs
... But URIs are quite different, you don't find that kind of discussion
... In most systems with a password or capability functionality
... you get discussion about protecting it/them
... But the focus for URIs is in the opposite direction: Put URIs on the side of a bus, dereference with GET

JR: That's a red herring

<masinter> "something you know, something you have, something you are"; password is "something you know", standard literature about how passwords fit into security architecture.

DC: Things change
... And yes, the specification of strings doesn't say anything about access control

<jar> noah: It's about spreading URIs around and accessing them freely

DC: So, passwords are strings that should be treated carefully
... URIs are the general case, you don't talk about security in the general case
... Some URIs are special, they should be protected

NM: But you don't use generic string functions for managing passwords
... whereas Tyler Close wants to use the generic URI functionality for these 'special' URIs

JK: Not sure this line of argument is helpful

<masinter> URIs are currently subject to more risks of disclosures than passwords normally are, through referer, server logs, crawlers and search engines

JK: Yes, we didn't anticipate the use of URIs as protected things, but we are seeing that now

<DanC> (the market has already adopted this change.)

<masinter> when advocating a new mechanism, it's important to analyzie the risk of using that mechanism in the deployed infrastructure world.

<DanC> (not only minimal security problems, *improved* security w.r.t. CSRF)

NM: The core issue is, if there's a problem, who is responsible?

<masinter> i disagree that "who is responsible" is the core

NM: Tyler is saying the leaving log files around is now, as a result of changes, a bad thing
... Are we prepared to change the rules to support this?

AM: I'm trying to figure out where the disagreement is
... DC said that some URIs are special, and ought to be protected - -do you agree?

NM: I don't think today's software should be expected to detect and protect those cases

LM: When you're proposing a new mechanism, the security analysis has to start with the world as it exists

<NoahM> I strongly agree with that. That's the crux for me.

LM: you can't say "My part will work if everyone changes everything else"

LM: It's fine to say the Web Keys are good for something, but not to go one to say "for them to be helpful, everyone has to change"

<NoahM> You very often can't promptly withdraw widely deployed software, even if you'd like to.

<DanC> (who is asking to withdraw deployed software? strawman.)

<Zakim> johnk, you wanted to note the Referer header

JK: But we're there already
... The use of the Referrer header is what's making us vulnerable to the CSRF bug

LM: It's not that the architecture was wrong, the designers made a mistake

Those referer headers will be sent for a long time, whether we like it or not.

<DanC> (the status quo as described in the finding leads to CRSF attacks. we absolutely should change what we advocate.)

<masinter> While I'm sympathetic to the intent, this leaves undefined the scope of "user agent" here, referent of "the user", and the meanings of "disclose", "legitimately", "confidential", "assume" and "third-parties". Does "user agent" apply to, say, archive.org (which might pick up a mailing list archive of an email and scan what is supposed to be a 'private' URL)? Does it apply to, say, news.google.com, which seems to aggregate news from newspapers that have a "news reader" registration and login requirements?

<masinter> from http://lists.w3.org/Archives/Public/www-tag/2010Feb/0099.html

LM: Talks about a case where a non-user agent, an aggregator, might be pertinent to the discusion.
... There is generally an assumption they make which is, that because there is no access control, they can share it further.

DC: Don't believe that.

LM: I do. People retweet URIs all the time.

<DanC> (forwarding is republishing... somewhat risky)

<jar> ??????

<DKA> I am having network issues and now must drop off.

LM: Don't like having to look at URI to see if secret.

<DanC> (larry, you've never sent somebody email saying "here's a link; don't spread it around just yet"?)

NM: Don't think anyone has called upon generic software to recognize secret URIs by inspection.

LMM: We're expecting users to be careful.

<masinter> i think that's an unreasonable expectation

<Zakim> DanC, you wanted to suggest a poll: who has seen text they're happy with in the metadata-in-uri-finding? which text? (including leaving it as is)

<masinter> and if you disagree with it, say why

<masinter> http://lists.w3.org/Archives/Public/www-tag/2010Feb/0099.html

Voting options:

1. No changes to metadata in URI

<DanC> (I'd rather the poll were about specific, existing text)

2. Leave all existing text, when risks believed acceptable, you can try secrets anyway.

<masinter> Ashok & JK said they agreed

<masinter> JAR asked for clarification

<johnk> JK said that the first piece of text was largely unenforceable, not that he agreed with the full text of Larry's email

NM: A proposal from me (Noah) is at the end of this email: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html

===Begin quote===

For the most part, the Web imposes no restrictions on the copying, logging, transcription, or redistribution of URIs. Such copying or redistribution may occur using the mechanisms of the Web itself (e.g. via HTTP), or through other means (URIs may be emailed, may be stored and retrieved from system logs, etc.) Nonetheless, there are may be particular circumstances in which the distribution of a URI is in fact limited, e.g. because the URI has been mailed to some particular user using an email system that is believed to be suitably secure for the purpose. In such cases, the value gained from using a URI as a capability mechanism, in which knowledge of a the URI is sufficient for access to or manipulation of protected information, may exceed the risks of inadvertent disclosure of the URI. Such use is acceptable. To avoid the risk that malicious parties could infer the URI(s) for some such resource(s), the mapping from publicly available information (resource metadata?) to the URI itself should be secret.

Good practice: use explicit security mechanisms to control access to Web resources, except when the risk that URIs will (leak? fall into the wrong hands?) is sufficiently low

Good practice: for resources that are not sufficiently protected by explicit security mechanisms, use URI's that cannot be inferred from publicly(?) available information.

=== end quote ===

<DanC> seriously? "this leaves undefined the scope of "user agent" here"? "user agent" is used in all sorts of specs to the satisfaction of the community.

<NM:> I got dropped.

<masinter> I think the security considerations need to combine the risk of disclosure with the consequences of inadvertent disclosure

<masinter> i think we're making progress on this issue

<masinter> and that we should continue by email based on refining my email and noahs

LM: unsubscription: (1) single use, (2) auditing, (3) limited impact

<NM:> We can take to email.

<masinter> ok

<DanC> I hate to adjourn without being clear who has the ball, but I don't have a better idea.

<NM:> Right, that's how I feel.

<DanC> "We can take to email." <- famous last words

<NM:> This is the sort of issue that generates lots of email that's hard to sort out, even if there are lots of good ideas.

<NM:> I welcome someone taking an action...that's the alternative.

30 secs, and I adjourn.

15 secs

We are adjourned, with my apologies for dropping unexpectedly.

Post-adjournment IRC discussion

<NM:> I am curious for comments on my proposal, quoted abvoe.

<NM:> prefer email though.

<DanC> yeah... unsubscription tests too many features at once; email callback is another layer of security on top of entropy in the URI

<DanC> NoahM, the 2nd GPN in your proposal looks pretty similar to the 2nd GPN in what tyler wrote; I don't see a clear distinction. As far as I have read so far, they're both OK by me...

<DanC> I haven't looked closely enough at what you wrote to see whether it adequately addresses CSRF problems.

<NM:> I certainly didn't say anything about what User Agents MUST NOT do. At least that's a very big difference I think. My version is much more "buyer beware"

<NM:> At best what I wrote needs some tuning, but it's pretty close to my current thinking.

<NM:> Also, while it's too wordy, I think the thought at the beginning of the intro para is significant.

<masinter> suggested ACTION: ask thomas & web-security group to take this up

<masinter> we've mainly been encouraging TLR to report on web security. This is a proposal for an alternate mechanism to address CSRF....

<NM:> Well, I still have concerns with some specifics of Tyler's proposals, but he has reached out to us, asking that we clarify the impact of one of our findings. I think we should try to work this through if we can.

<NM:> I'm intrigued that Dan views what I wrote as not far from Tyler's proposal, and also that his first reaction is that it might not be too far off. What do you think of it, Larry?

<masinter> well, I think we've done quite a bit; i think i've spent many hours working trhough the technology

<masinter> Noah: <masinter> I think the security considerations need to combine the risk of disclosure with the consequences of inadvertent disclosure

<masinter> and how the risks of inadvertent disclosure are mitigated. Such as: unsubscribe link requires explicit POST, results in a ocnfirmation email being sent and undone, is only valid for a limited time and only one-time.

<masinter> that we shouldn't unreservedly recommend "secret passwords" as a security mechanism, but note that there are some ways of avoiding the risks associated with them for some information which is "confidental".

<masinter> I think most email unsubscription links follow the practices I'm suggesting, so this isn't inconsistent with "good practice".

<masinter> i said 'undone' but i meant 'undoable'

<masinter> generally unsubscribing from a mailing list is really helpful, not harmful. so secret URIs shouldn't be used for things that cause irrecoverable harm if revealed.

<masinter> releasing a document that isn't ready for release, for example ... you might not want the world to read your DRAFT document and comment on it as if it were your final word, but it might be OK to use a secret URI for it if the only harm is that someone will read something you can disavow

<masinter> that's often the use case for google docs kinds of things -- you don't really care if people can find it out, you just don't want anyone to think it's authoritative.

<masinter> I use 'secret URIs' for that use case a lot. It's a draft for me and my friends, i don't link it to my home page, but if someone finds it, no big deal.