W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

TAG telcon: Draft minutes of call on 2010-02-11

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 16 Feb 2010 22:26:39 +0000
To: www-tag@w3.org
Message-ID: <f5bvddwyfz4.fsf@calexico.inf.ed.ac.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Available online as

 http://www.w3.org/2001/tag/2010/02/11-minutes.html

and below in text form.

ht
- -----------------
                                   - DRAFT -

                                  TAG telcon

                                  11 Feb 2010

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
          Dan  Connolly, Dan Applequist, John Kemp, Ashok Malhotra, Larry
          Masinter, Noah Mendelsohn, T. V. Raman, Jonathan Rees, Henry S.
          Thompson

   Regrets
          Tim Berners-Lee

   Chair
          Noah Mendelsohn

   Scribe
          Henry S. Thompson

Contents

     * [4]Topics
         1. [5]Admin
         2. [6]ISSUE-58 & ACTION-163: Sample catalog
         3. [7]ACTION-345: Widget / Phonegap Convergence
         4. [8]ACTION-367: Microdata bug report to HTTP WG
         5. [9]ACTION-278: Draft changes to 2.7 of Metadata in URIs to cover
            the "Google Calendar" case
         6. [10]Post-adjournment IRC discussion
     _________________________________________________________________

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 [11]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

   [12]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> [13]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> [14]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> [15]Coordination issue: vCard, iCalendar vs JavaScript contact and
   calendaring APIs Thomas Roessler (Wednesday, 27 January)

   <masinter> vcarddav, calsify

   <masinter>
   [16]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> [17]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:
   [18]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0099.html

   <NoahM> Response from chair:
   [19]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> [20]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, [21]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]?

   [22]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:
   [23]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
   [24]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> [25]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
   [26]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> [27]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: My proposal is at the end of:
   [28]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.
     _________________________________________________________________


    Minutes formatted by David Booth's [29]scribe.perl version 1.134 ([30]CVS
    log)
    $Date: 2010/02/16 22:24:24 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/2001/tag/2010/02/11-agenda.html
   3. http://www.w3.org/2010/02/11-tagmem-irc
   4. http://www.w3.org/2001/tag/2010/02/11-minutes.html#agenda
   5. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item01
   6. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item02
   7. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item03
   8. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item04
   9. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item05
  10. http://www.w3.org/2001/tag/2010/02/11-minutes.html#item06
  11. http://www.w3.org/2001/tag/2010/02/04-tagmem-minutes
  12. http://www.w3.org/2001/tag/2010/01/28-minutes
  13. http://www.w3.org/2001/tag/group/track/issues/58
  14. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0045.html
  15. http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Jan/0000.html
  16. http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Jan/0001.html
  17. http://www.w3.org/2001/tag/group/track/actions/367
  18. http://lists.w3.org/Archives/Public/www-tag/2009Dec/0099.html
  19. http://lists.w3.org/Archives/Public/www-tag/2010Jan/0001.html
  20. http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220
  21. http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220
  22. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0051.html
  23. http://lists.w3.org/Archives/Public/www-tag/2010Jan/0087.html
  24. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0081.html
  25. http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.1
  26. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0099.html
  27. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0099.html
  28. http://lists.w3.org/Archives/Public/www-tag/2010Feb/0074.html
  29. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  30. http://dev.w3.org/cvsweb/2002/scribe/

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFLexufkjnJixAXWBoRAkZMAJ4rdGXmMiIra3FjjOsMJwqE6eJGrwCfVm5C
KQZAOE+Fw0P3FnzKIY2T83s=
=QVYg
-----END PGP SIGNATURE-----
Received on Tuesday, 16 February 2010 22:27:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:19 GMT