- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Tue, 16 Feb 2010 22:26:39 +0000
- To: www-tag@w3.org
-----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 UTC